Solutions · Services financiers
Une application pour les services financiers se juge à ce qui se passe à ses marges : ce qui est écrit dans le journal, ce qui se passe lorsque le client demande la restitution de ses données, ce qui apparaît dans l’information précontractuelle et ce qui se passe lorsqu’une tâche planifiée ne s’exécute pas. Nous construisons la mécanique ; la politique de crédit reste la vôtre.
Déjà construitO platformă de creditare în producție, verificabilă din exterior azi: partea publică e o aplicație compilată static cu 50 de ecrane, între care patru calculatoare — credit, eligibilitate, refinanțare, grafic de plăți — pagini pe tip de credit, informare precontractuală și o rută prin care clientul își cere datele personale; partea de business e un backend modular în TypeScript cu 16 module și 18 tabele în schema de date, între care contract, plată, jurnal de audit, cerere privind datele personale, document încărcat, instantaneu zilnic de indicatori și rulare de sarcină programată. Harta de site de pe producție listează 227 de adrese, iar rutele românești și cele rusești răspund amândouă — verificate de mine pe 06.09.2026. Rezerva pe care o spunem: dovada e din cod și din răspunsurile publice, nu din comportamentul intern al serverului — nu am verificat pe ce versiune rulează producția și nici că toate cele 16 module sunt active pe live.
Une société de crédit n’a pas besoin d’un site. Elle a besoin d’une chaîne complète : la demande arrive en ligne, passe par un flux de décision, produit un contrat, génère un échéancier de paiement et laisse une trace dans l’audit. Chaque maillon manquant dans la chaîne se transforme en une personne qui copie des données d’un endroit à un autre, et dans les services financiers chaque copie manuelle est aussi un problème de conformité, pas seulement de temps.
La structure que nous construisons le reflète directement dans les données. Dans la plateforme que nous citons, le schéma comporte 18 tables, et leur liste en dit plus que n’importe quelle description d’architecture : demande, contrat, paiement, code à usage unique, session, demande d’appel, modèle de notification, journal de notifications, instantané quotidien d’indicateurs, exécution de tâche planifiée, article, redirection d’adresse, paramètre de visibilité, note interne, journal d’audit, document téléchargé, demande concernant les données personnelles. Le backend est réparti en 16 modules, parmi lesquels un exclusivement dédié aux droits de la personne concernée.
La partie publique n’est pas un décor : quatre calculateurs — crédit, éligibilité, refinancement et échéancier de paiement — plus des pages séparées par type de crédit et l’information précontractuelle. Dans le crédit à la consommation, l’information précontractuelle n’est pas une page vitrine : c’est l’obligation d’afficher les conditions avant que la personne ne s’engage. Nous la traitons comme une exigence du produit, et non comme un texte juridique collé à la fin. Les routes roumaines restent sans préfixe, et les routes russes passent par un segment propre, avec des libellés canoniques et des alternatives générées à partir de la langue de la route active.
Et la limite qui doit être dite avant le contrat : le flux de décision sur les demandes — les règles, les seuils, l’approbation — est le vôtre. Nous construisons la mécanique par laquelle la demande circule, est documentée et devient contrat. Nous n’écrivons pas la politique de crédit et nous n’assumons pas l’évaluation d’un demandeur ; ce sont des décisions aux conséquences juridiques qui relèvent de l’institution autorisée.
Ce que cela comprend
La demande arrive en ligne et vit comme une entité propre, avec un état visible et un écran de suivi pour le client. Les documents téléchargés ont leur table, le contrat a sa table, le paiement la sienne. La différence avec un formulaire qui envoie un e-mail, c’est qu’après trois mois on peut répondre à partir des données à la question « que s’est-il passé avec la demande du 12 mars ».
Le contrat et l’échéancier ne sont pas composés manuellement dans un document séparé : ils sont issus des données de la demande approuvée. C’est la seule variante dans laquelle le chiffre du contrat et le chiffre de l’échéancier ne peuvent pas diverger, et le client qui appelle avec le document en main parle de la même chose que l’opérateur qui regarde dans le système.
Crédit, éligibilité, refinancement et échéancier de paiement — des écrans séparés, publics, sans authentification. Dans le crédit à la consommation, le calculateur est la première interaction réelle : la personne veut voir la mensualité avant de parler à quelqu’un. Et le refinancement est un calculateur différent de celui du crédit, pas le même avec d’autres libellés.
Page propre, pas un paragraphe en bas de page. La raison est pratique : si l’information ne se trouve pas sur le parcours que la personne suit avant de signer, elle ne remplit sa fonction ni pour elle, ni pour l’institution. Le texte est le vôtre et celui de vos juristes ; nous construisons l’emplacement, le moment et la traçabilité.
Il existe une page publique par laquelle le client demande ses données personnelles, un module backend dédié et un écran d’administration pour les demandes reçues, ainsi qu’une table dans laquelle elles vivent. Conséquence pratique : le délai légal de réponse peut être respecté sans que quelqu’un ouvre manuellement la base de données — et l’on peut démontrer, dans un an, qu’il a été respecté.
Le journal d’audit est une table propre, distincte des notes internes des opérateurs. La séparation compte lors d’un contrôle : d’un côté, il y a l’enregistrement technique de ce qui s’est passé ; de l’autre, ce qu’un collègue a écrit sur un dossier. Mélangés, le premier devient illisible et le second devient un document.
Il existe une table pour les exécutions des tâches planifiées et une autre pour les instantanés quotidiens d’indicateurs. Dans une plateforme financière, une tâche qui n’a pas tourné trois nuits de suite est un problème plus grave qu’une page en panne : cela ne se voit pas de l’extérieur, mais cela déplace les chiffres. C’est pourquoi l’exécution est écrite, et non supposée.
Les routes roumaines restent sans préfixe, les routes russes passent par un segment propre, avec des étiquettes canoniques et des alternatives générées à partir de la langue de la route active. Sur la carte du site en production, il y a 227 adresses. Pour une entreprise de crédit de la République de Moldova, la partie russe n’est pas une traduction de courtoisie — c’est la moitié des demandeurs.
Vérifications avant publication, migrations de base de données exécutées avec une commande séparée en production, génération de secrets, copie de sauvegarde et restauration de la base — tout cela sous forme de scripts dans le dépôt, pas comme des étapes d’un document. Dans un système qui gère des contrats et des paiements, « restauration » doit être une commande que vous avez essayée, pas une intention.
Traseul
Ce que signifie une demande déposée, une demande approuvée, un paiement encaissé ; ce qui se passe avec une demande à laquelle on n’a pas répondu ; ce qui se ferme lorsqu’un service externe ne répond pas. Nous livrons le document de vocabulaire et d’invariants, car dans une plateforme financière un terme utilisé en deux sens devient, plus tard, deux chiffres différents dans deux rapports.
Le journal d’audit et l’enregistrement des documents ne s’ajoutent pas à la fin ; ils font partie de la première version qui fonctionne. Nous livrons le flux complet de la demande au contrat, avec sa trace, sur des données de test — pas des écrans qui ont belle allure au-dessus d’une base vide.
Les écrans publics, les calculateurs, les pages par type de crédit et l’information précontractuelle, avec les adresses roumaines sans préfixe et les adresses russes sur un segment propre, avec des étiquettes canoniques correctes. Nous livrons la carte du site générée à partir des données et la vérification que les deux versions répondent.
Vérification avant publication, migrations en production avec commande séparée, génération de secrets, copie de sauvegarde et restauration — éprouvées, pas seulement écrites. Nous remettons le dépôt, le document de mise en service et les accès. La restauration de la base est démontrée à la remise, une fois, devant vous.
Les données
Les règles diffèrent d’un secteur à l’autre. Voici celles qui s’appliquent aux services financiers.
Un cas
La situation
L’exigence initiale dans un projet de crédit sonne presque toujours pareil : « un site avec formulaire de demande ». Le problème apparaît au deuxième mois, quand quelqu’un demande où est le contrat, qui a modifié le dossier et comment nous répondons à une demande d’accès aux données personnelles dans le délai légal.
Ce que nous avons construit
Nous avons construit la plateforme en deux moitiés, dans le même dépôt. La partie publique est une application compilée statiquement, avec 50 écrans : quatre calculateurs — crédit, éligibilité, refinancement, échéancier de paiement — des pages par type de crédit, l’information précontractuelle, le suivi de l’état de la demande et une page par laquelle le client demande ses données personnelles. La partie business est un backend modulaire en TypeScript, avec 16 modules — parmi lesquels l’authentification, les droits par rôle, le flux des demandes, les documents, les paiements, les notifications, les tâches planifiées et un module dédié aux droits de la personne concernée — au-dessus d’un schéma avec 18 tables : demande, contrat, paiement, code à usage unique, session, document téléchargé, journal d’audit, demande concernant les données personnelles, exécution de tâche planifiée, instantané quotidien d’indicateurs et le reste.
Ce qui en est sorti
La chaîne est complète : la demande entre, circule, produit un contrat et un échéancier, et chaque étape laisse une trace. Les demandes concernant les données personnelles ont leur propre parcours, avec un écran d’administration, donc le délai légal peut être respecté et démontré. La partie publique est vérifiable de l’extérieur : 227 adresses dans la carte du site, avec les deux versions linguistiques actives.
Ce que le cas ne dit pas
La preuve vient du code et des réponses publiques, pas du comportement interne du serveur : nous n’avons pas vérifié sur quelle version tourne la production et ni que tous les 16 modules sont actifs en live. Le flux de décision sur les demandes — règles, seuils, approbation — appartient au client ; nous avons construit la mécanique, pas la politique de crédit.
Questions
Vous. Les règles, les seuils et l’approbation relèvent de la politique de l’institution autorisée, pas du fournisseur de logiciel. Nous construisons la mécanique par laquelle la demande circule, est documentée, devient contrat et échéancier de paiement, et laisse une trace. Un fournisseur qui s’approprie la décision de crédit vend quelque chose qu’il n’a pas le droit de vendre.
Il existe une page publique par laquelle il en fait la demande, un module backend dédié, un écran d’administration et une table dans laquelle la demande vit. On peut donc répondre dans les délais et le démontrer ensuite. Ce qui n’est pas une décision technique : ce qui peut être supprimé et ce qui doit être conservé conformément à la législation financière — cela se décide avec vos juristes, avant l’implémentation.
À partir des données de la demande approuvée, avec le tableau des paiements — les deux provenant de la même source, afin qu’ils ne puissent pas différer. Ce qui reste à votre charge, c’est le contenu du contrat et ses conditions. Un contrat rédigé manuellement dans un document séparé est l’endroit classique où apparaissent deux chiffres différents pour le même prêt.
Parce qu’en crédit à la consommation, l’information doit se trouver sur le parcours que la personne suit avant de s’engager, et non dans un pied de page. Nous la traitons comme une partie du produit : l’emplacement, le moment et la traçabilité sont à nous, le texte est celui de vos juristes.
Au minimum de ceux qui correspondent à des décisions différentes. Sur la plateforme que nous citons, ils sont quatre — crédit, éligibilité, refinancement, tableau des paiements — parce que le refinancement n’est pas le même calcul qu’un nouveau crédit, et que le tableau répond à une autre question que le taux. Un seul calculateur avec de nombreux champs est plus difficile à utiliser que quatre simples.
Non, et c’est une règle, pas une préférence : nous construisons et testons sur des données de test. L’accès aux données réelles, lorsqu’il est nécessaire, se fait avec des personnes nommées, pour une période définie et avec une trace dans le journal. Dans un système financier, « j’ai eu besoin de regarder en production » est une phrase qui doit apparaître dans un journal, pas dans une discussion.
Cela se voit, parce que les exécutions sont consignées dans une table propre, à côté des instantanés quotidiens d’indicateurs. C’est important précisément parce qu’une tâche qui ne s’est pas exécutée ne produit aucun symptôme visible de l’extérieur — le site répond, les écrans sont corrects, mais les chiffres ne bougent plus.
Aucun chiffre de volume, de taux, de nombre de demandes ou de clients, même s’il est affiché publiquement sur son site — parce qu’il s’agit de son affirmation, pas de notre mesure. Ce que nous pouvons montrer, c’est la structure : combien de modules, quelles tables, quels écrans publics, ce qui est vérifié à la publication. La même règle s’appliquera à votre travail.
La partie publique peut être vérifiée maintenant : la carte du site comporte 227 adresses, et les versions roumaine et russe d’un calculateur répondent toutes deux. La partie backend se lit dans le code — modules et schéma de données — et non dans le comportement du serveur : nous n’avons pas vérifié sur quelle version la production fonctionne, ni si tous les modules sont actifs en live, et nous préférons l’écrire plutôt que de laisser une impression contraire.
Racontez-nous votre processus. Ensemble, nous décidons ce qui vaut la peine d'être construit, ce que nous pouvons connecter et comment nous vérifions le résultat.