Expertise · Logiciel sur mesure

Un système construit pour la manière dont votre organisation travaille, et non pour le cas général.

Nous construisons des systèmes de zéro, lorsqu’aucun produit du marché ne convient : des plateformes avec plusieurs applications et une base de données commune, des connecteurs vers des systèmes qui n’ont pas d’API, des pipelines qui lisent des documents et des mouvements d’argent, et des programmes dont le résultat n’est pas un écran, mais un dossier de fabrication. À la fin, nous remettons le dépôt, le document de mise en service et les accès.

Discuter d'un projet

Déjà construitJ’ai choisi quatre systèmes propres issus de disciplines différentes, justement pour qu’ils ne ressemblent pas à quatre variantes du même site, et j’ai exécuté aujourd’hui les tests de chacun. Un monorepo avec 3 applications et 12 paquets, 486 fichiers TypeScript et 68 fichiers de test, 151 commits, arbre de travail propre. Un système d’interrogation de deux portails B2B sans API publique : 38 tests réussis en 0,52 s, sur des réponses réelles sauvegardées sous forme de fixtues. Un pipeline qui lit des notifications bancaires depuis des e-mails et des PDF et les écrit dans Postgres avec déduplication par empreinte. Et un générateur de documentation d’ingénierie, en Python, avec 44 tests réussis en 0,50 s. Les chiffres proviennent de mes exécutions du 6 septembre 2026, pas des README.

« Sur mesure » signifie que le système est écrit selon la manière dont vos équipes travaillent déjà, et non l’inverse. Il y a un coût qu’il est honnête d’annoncer d’avance : quelqu’un devra le maintenir, et ce quelqu’un, c’est nous ou votre équipe. C’est pourquoi la première question que nous vous posons n’est pas ce que vous voulez construire, mais s’il existe déjà un produit qui fait 80 % du travail. S’il existe, nous le disons, même si cela signifie que vous ne nous confiez pas le travail. Ce qui reste après cette question — la partie qui ne s’achète pas — est exactement ce que nous construisons bien.

L’ampleur se voit plus clairement à travers quatre systèmes différents qu’à travers une liste de technologies. Le premier est une plateforme pour une institution de spectacles : un monorepo avec trois applications (site public, espace administratif, API) et douze paquets communs — billets, commerce, contenu, notifications, remboursements, sécurité. Le deuxième interroge, à la demande, les portails B2B de tour-opérateurs qui ne publient aucune API : authentification programmatique, retour à la connexion lorsque la session expire, et un analyseur testé sur des réponses réelles capturées dans des fichiers. Le troisième lit des notifications bancaires depuis des e-mails et des relevés PDF et les place dans Postgres. Le quatrième n’a pas d’écran du tout : c’est le programme qui génère le modèle, la nomenclature des matériaux et les plans d’une machine industrielle.

Ce qui maintient un tel système debout, ce n’est pas la pile, mais les règles écrites avant le premier écran. Dans la plateforme pour l’institution de spectacles, le contrat de mise en œuvre fixe dans le texte des choses qui, autrement, se négocient à chaque réunion : l’argent est conservé en unités monétaires mineures entières, avec la devise à côté ; la disponibilité d’une place est donnée uniquement par une réservation durable dans la base de données, jamais par le cache ; les commandes critiques ont des clés d’idempotence ; les voies P0 et P1 tombent en fermeture, non en ouverture ; les données de carte ne sont jamais stockées. Ces règles s’écrivent au début parce que, écrites à la fin, elles impliqueraient de réécrire le système.

À la fin, trois choses sont livrées, pas une : le dépôt avec tout son historique, le document qui explique comment le mettre en service sur un serveur vide, et les accès. Sous notre répertoire de projets se trouvent 150 dépôts git, 103 fichiers README et 19 documents de mise en service ou de remise — comptés aujourd’hui, non estimés. La règle de propriété, nous l’écrivons dans le contrat avant le démarrage et elle est simple : le code écrit spécialement pour vous vous appartient, les bibliothèques tierces restent sous leur licence, et nos composants réutilisables ainsi que nos produits sont licenciés, non cédés. Si une partie du travail se résout mieux avec un de nos produits, nous vous le disons exactement ainsi, afin que vous sachiez dès le départ ce que vous achetez et ce que vous recevez.

Ce que cela comprend

Le travail, par composantes

Nous écrivons les règles du domaine avant le premier écran

Un contrat de mise en œuvre, en texte, qui fixe le vocabulaire et les invariants : ce que signifie une place réservée, ce que signifie un paiement encaissé, ce qui tombe en fermeture lorsqu’un service ne répond pas. Dans la plateforme pour l’institution de spectacles, les règles sont explicites — l’argent en unités monétaires mineures entières plus la devise, la disponibilité uniquement à partir de réservations durables dans la base de données, des clés d’idempotence sur les commandes critiques, le cache jamais source de vérité pour le stock, les données de carte jamais stockées. Ce sont des règles qui se vérifient dans le code, pas des principes.

Nous construisons le noyau avec des tests qui s’exécutent sans le système vivant

Les réponses réelles des systèmes externes sont sauvegardées comme fixtures et l’analyseur est testé dessus, non sur le portail qui peut être hors service exactement le jour où vous travaillez. Pour le système d’interrogation des portails de vols, la suite s’exécute en 0,52 seconde et passe intégralement ; les tests qui touchent réellement les portails sont marqués séparément et sont demandés explicitement. La même séparation existe dans les quatre systèmes : ce qui peut être vérifié sur table est vérifié sur table.

Nous livrons le dépôt, la mise en service et les accès

Pas un fichier zip. Le dépôt avec l’historique des commits, un document qui décrit comment le système est mis en place sur une machine vide — base de données, variables d’environnement, service système, serveur web en frontal — et les accès qui en font le vôtre. Sous notre répertoire de projets existent aujourd’hui 150 dépôts git, 103 README et 19 documents de type DEPLOY ou HANDOVER ; cette forme de remise est l’habitude, pas l’exception.

Quand le système de l’autre côté n’a pas d’API, nous disons quel risque vous prenez

Les portails B2B que nous interrogeons ne publient pas d’interface programmatique, donc l’authentification se fait comme celle d’un utilisateur, avec cookie de session et clé de connexion, et est rétablie automatiquement à l’expiration. Le risque est écrit dans le README du projet, non découvert ensuite : l’authentification programmatique est une zone grise par rapport aux conditions d’utilisation du portail, et pour un volume de production élevé la bonne solution est de demander à l’opérateur son API officielle. Un client a le droit d’apprendre cela avant de signer, pas après.

Les documents n’entrent qu’une seule fois, même si nous les lisons dix fois

Chaque transaction extraite d’une notification bancaire ou d’un relevé PDF reçoit un identifiant externe calculé comme empreinte SHA-256 sur ses champs, et l’insertion dans Postgres se fait avec `ON CONFLICT (external_id) DO NOTHING`. Conséquence pratique : la boîte aux lettres peut être relue autant de fois que vous voulez, et le solde ne se double pas. Sans cette règle, tout pipeline d’ingestion finit par produire des doublons, c’est-à-dire un problème de comptabilité.

La classification avec un modèle se fait par des outils, pas par du texte libre

Le modèle n’écrit pas une phrase que nous devinons ensuite : il reçoit sept outils — paiement client, salaire, impôt, paiement au créancier, dépense d’exploitation, inconnu — et doit en choisir un, avec un score de confiance entre 0 et 1. Pour le rapprochement approximatif des noms de contrepartie, il existe une réserve séparée, basée sur la similarité des vecteurs. « Inconnu » est une sortie légitime, avec motif, pas un échec caché.

Parfois le résultat n’est pas un écran, mais un dossier

Un système propre en Python génère le modèle tridimensionnel d’une machine industrielle, la liste des matériaux avec le statut de libération pour chaque position, le plan de vérification, le schéma de câbles et les planches PDF — d’une seule commande, afin que rien du paquet ne puisse rester derrière le modèle. Il comporte 44 tests qui passent en une demi-seconde et qui vérifient des règles d’ingénierie, pas seulement le code : que le domaine actif fait exactement un mètre cube, qu’aucune position de la liste des matériaux ne reste sans ligne de vérification, que la machine n’extrude jamais au repos.

La mesure continue est une autre discipline que l’interrogation à la demande

Un système propre capte simultanément plusieurs stations de radio avec `ffmpeg`, transcrit localement avec un modèle open source, puis recherche des publicités avec un score transparent par groupes de signaux en roumain et en russe, avec un seuil configurable, et regroupe la même publicité diffusée sur différentes stations grâce à une empreinte audio de type chromaprint — parce que les transcriptions divergent, mais le son est identique. Il dispose de 81 tests qui passent en 1,14 seconde. Un système qui fonctionne sans surveillance a besoin de compteurs de couverture, de nouvelles tentatives avec location de tâche et d’un autotest, sinon il se tait quand il tombe en panne.

Nous disons aussi ce que nous ne construisons pas

Nous ne construisons pas de zéro ce qui se résout avec un produit existant, le nôtre ou celui de quelqu’un d’autre, simplement parce que le travail serait plus important. Nous ne reprenons pas de systèmes que nous ne pouvons pas exécuter localement, avec des données de test, jusqu’à la fin de la première étape. Et nous ne lançons pas un système qui dépend d’un fournisseur externe avant de vérifier quelle porte publique possède ce fournisseur — cette vérification est la première, pas la dernière.

À quoi cela ressemble

Le parcours, étape par étape.

Nous délimitons le domaine et écrivons les règles

Une étape de lecture des systèmes et d’échange avec les personnes qui font le travail aujourd’hui, achevée par un court document avec le vocabulaire, les invariants et ce qui est fermé. Nous livrons ce document même s’il n’y a pas de construction — il est utile sans nous. Il comprend aussi la liste des systèmes externes dont dépend le travail et la vérification de la porte publique de chacun, parce que c’est de là que viennent les surprises.

Nous construisons le noyau, avec ses tests, avant les écrans

Les règles du domaine, les modèles de données, les analyseurs, les calculs — plus les tests qui s’exécutent sans les systèmes vivants, sur des fixtures capturées à partir de réponses réelles. Nous livrons la suite et son résultat, avec la commande d’exécution, afin que vous puissiez la lancer vous-même. Un noyau qui ne peut pas être testé sans l’environnement de production est un noyau que nous ne pouvons pas réparer rapidement plus tard.

Nous ajoutons l’interface et les intégrations au-dessus du noyau

Le cabinet administratif, les écrans publics, les points d’entrée pour d’autres systèmes. Ici se branchent les fournisseurs externes, chacun avec un adaptateur propre et une variante de simulation, afin que le système puisse être exécuté intégralement sans comptes réels. Nous livrons aussi le mode d’exécution local, avec base de données et services démarrés depuis des conteneurs.

Nous mettons en service et remettons

Installation sur l’infrastructure convenue, service système, serveur web en frontal, journaux et leur rotation, autotest. Puis la remise : dépôt, document de mise en service rédigé pour une machine vide, accès, et un tour d’horizon de ce qu’il reste à faire. Ce qui n’a pas eu le temps d’entrer dans le travail est écrit comme une liste, n’est pas laissé non dit.

Trois étapes et leur ordre, qui constitue la moitié du travail. D’abord les règles du domaine écrites en texte — ce qu’est un emplacement réservé, comment les fonds sont gérés, ce qui tombe fermé quand un service se tait. Ensuite le noyau avec ses tests, qui s’exécutent sur des réponses réelles sauvegardées comme fixtures, sans systèmes vivants. Enfin la mise en service et la remise : dépôt, document pour une machine vide, accès. La flèche de retour de l’étape trois à l’étape un est réelle : ce qui se découvre à la mise en service change les règles, ne se cache pas dessous.

Les données

Ce que nous touchons, où elles sont et combien de temps elles restent

Les questions que pose toute personne ayant un délégué à la protection des données — posées ici avant qu'il ne les pose.

Où cela fonctionne et qui tient la clé: Le système fonctionne sur l’infrastructure convenue par écrit au début : votre serveur, un serveur administré par nous, ou un fournisseur d’hébergement choisi ensemble. Les quatre systèmes ci-dessus fonctionnent différemment les uns des autres — l’un comme service système derrière un serveur web, l’un depuis des conteneurs, l’un comme processus planifié sur une machine locale, l’un seulement à la commande, sur le poste de travail. Le choix est pris à partir des contraintes des données, pas de l’habitude.
Les identifiants ne restent pas dans le code et, lorsque c’est possible, pas non plus sur le disque: Les mots de passe et les clés sont lus depuis des variables d’environnement, et le fichier qui les contient est restreint à l’utilisateur courant. Dans un connecteur vers un système externe, le jeton de session est conservé uniquement en mémoire et est renouvelé à l’expiration ou au premier refus — le mot de passe et le jeton ne sont écrits dans aucun fichier. La règle est vérifiée lors de la revue : une clé arrivée dans le dépôt est un incident, pas une fuite.
Les données qui entrent depuis les documents: Lorsque le système lit des e-mails ou des PDF, il touche à des données réelles de l’activité : montants, dates calendaires, noms de contrepartie, numéros de compte. Elles sont stockées dans la base de données du bénéficiaire, avec un identifiant propre, qui ne peut pas être répété, par enregistrement, et peut être reconstitué à partir de la source. Ce qui part vers un modèle externe, si l’un est utilisé, est la description de la transaction — pas le document entier ni la pièce jointe.
Ce qui est conservé et pendant combien de temps: La durée de conservation se fixe par type de données, et non globalement, et elle s’écrit avant la mise en service : les enregistrements métier selon les obligations légales du bénéficiaire, les journaux techniques sur une courte fenêtre, les fichiers intermédiaires — captures audio, pièces jointes téléchargées — avec nettoyage automatique. Un système qui n’a pas de politique de suppression devient, en six mois, un risque plus grand que le problème qu’il résolvait.
Ce qui reste chez nous après la remise: Après la remise, notre accès à vos systèmes n’existe que s’il existe un contrat de maintenance qui l’exige, et il est retiré quand celui-ci prend fin. Les copies de travail sur nos stations sont supprimées sur demande. Ce que nous conservons en tout cas, ce sont les composants génériques que nous avons écrits et qui ne contiennent pas vos données — et ceux-là, nous les déclarons dès le départ, pour qu’il n’y ait pas de surprise à la fin.

Un cas

Un système d’interrogation pour deux portails sans aucune API

La situation

Une agence de voyage avait besoin, à la demande, de la disponibilité des places et des tarifs sur les vols charter des portails B2B de deux tour-opérateurs. Les portails sont conçus pour l’œil humain : vous vous connectez, vous cherchez, vous lisez un tableau. Il n’existe pas d’interface programmatique publiée, et l’information était relue manuellement, plusieurs fois par jour, par une personne.

Ce que nous avons construit

J’ai écrit un client qui s’authentifie de manière programmatique et renouvelle sa session quand elle expire, un analyseur qui transforme les réponses en objets et une couche d’identifiants pour les aéroports, où le code est formé de la ville et du port, et où certains appels demandent les deux parties séparément. Par-dessus : une commande en ligne qui renvoie un itinéraire complet avec disponibilité et prix, un mode de requêtes par lots avec des pauses entre elles pour éviter le blocage du compte, et deux points d’entrée JSON pour le cas où une autre plateforme voudrait consommer le résultat. L’analyseur est testé sur des réponses réelles, enregistrées comme fixtures dans le dépôt, et les tests qui touchent réellement les portails sont marqués séparément et ne s’exécutent pas par défaut.

Ce qui en est sorti

La suite passe intégralement : 38 vérifications en 0,52 seconde, sans toucher aux portails. Une requête renvoie, dans une seule réponse, la disponibilité dans les quatre états utilisés par le portail et le tarif avec classe et bagage, dans la monnaie demandée. Le résultat peut être consommé depuis la ligne de commande, en JSON, ou via les deux points d’entrée HTTP.

Ce que le cas ne dit pas

L’authentification programmatique reste une zone grise vis-à-vis des conditions d’utilisation des portails, et cela est écrit dans le README du projet, non découvert après la livraison. Pour un volume de production élevé, notre recommandation est explicite : il faut demander l’API officielle aux opérateurs. Le système fait des requêtes ponctuelles et met des pauses entre elles précisément pour ne pas devenir un outil d’extraction en masse.

Questions

Ce que les gens nous demandent avant d'appeler

Pourquoi aucun prix n’est-il indiqué sur cette page ?

Parce que nous ne pourrions pas l’indiquer honnêtement. L’effort d’un système sur mesure dépend de trois choses que nous ne connaissons pas avant d’avoir regardé : combien de systèmes externes doivent être touchés et si l’un d’eux dispose d’une API, combien de règles métier sont déjà écrites quelque part et combien doivent être découvertes auprès des personnes, et qui maintient le système en vie après la livraison. Un chiffre donné avant d’avoir vu le système est une devinette avec facture. Ce que nous pouvons faire rapidement, c’est la première étape — lecture, délimitation, écriture des règles —, qui se chiffre correctement et reste utile même si vous vous arrêtez là.

Qui détient le code à la fin ?

Le code écrit spécialement pour vous vous appartient, avec le dépôt et l’historique. Les bibliothèques tierces restent sous leurs licences — nous ne pouvons pas vous les céder, car elles ne sont pas à nous. Nos composants réutilisables et nos produits existants sont concédés sous licence pour utilisation, ils ne sont pas transférés ; si votre projet s’appuie sur l’un d’eux, nous vous le disons dans l’offre écrite, avant le démarrage, pas à la dernière réunion.

Que se passe-t-il si nous voulons continuer avec quelqu’un d’autre ?

La remise doit rendre cela possible sans nous, sinon ce n’était pas une remise. C’est pourquoi le document de mise en service est rédigé pour une machine vide et ne suppose rien de notre part, et les tests restent dans le dépôt pour que l’équipe suivante sache ce qui se casse lorsqu’elle modifie. Ce que nous ne pouvons pas promettre, c’est qu’un système complexe se reprend sans effort — nous pouvons seulement promettre qu’il ne manque rien de ce qu’il faut pour qu’il soit repris.

Puis-je voir un système construit par vous, pour juger la qualité ?

Partiellement, et il est juste de dire où cela s’arrête. Les systèmes construits pour des clients ne sont pas à nous pour les montrer, et les systèmes internes contiennent des données réelles de business. Ce que nous pouvons faire devant vous, à l’écran, est autre chose : nous ouvrons le dépôt, nous vous montrons les règles du domaine écrites en texte, nous lançons les suites de tests — 38 en une demi-seconde sur l’un, 81 en un peu plus d’une seconde sur un autre, 44 sur le troisième — et nous lisons ensemble le code qui fait l’affirmation que vous mettez en doute. Ce site, lui aussi, est un système propre qui peut être inspecté de l’extérieur.

Notre ancien système n’a pas d’API. Peut-on faire quelque chose ?

En général oui, mais avec un risque déclaré. L’ordre est le suivant : d’abord, nous demandons si le fournisseur dispose d’une API officielle qu’il n’a tout simplement pas documentée publiquement — cela arrive souvent. S’il n’en a pas, on peut travailler via une authentification programmatique, exactement comme un utilisateur, avec une session renouvelée automatiquement ; nous avons construit ainsi un système qui interroge deux portails B2B. Nous vous écrivons alors clairement que c’est une zone grise par rapport aux conditions d’utilisation du fournisseur et que, pour un gros volume, la solution durable est de demander l’API officielle. La décision vous revient, mais de façon éclairée.

Utilisez-vous l’intelligence artificielle pour écrire le code ?

Oui, et nous ne le cachons pas. Ce qui compte, ce sont les règles dans lesquelles cela se fait : chaque morceau de travail se termine par des tests exécutés, une vérification des types et une revue des diffs avant le commit, et les limites sont écrites dans le dépôt — pas de mise en production depuis l’intérieur du travail, pas de modifications sur des comptes externes, adaptateurs pour les fournisseurs uniquement avec une version de simulation. Un code écrit vite et non vérifié coûte plus cher qu’un code écrit lentement. Ce qui se vend ici, c’est la rapidité sur la partie ennuyeuse, pas l’absence de vérification.

Que faites-vous quand, en cours de route, il s’avère que l’idée initiale était mauvaise ?

Nous le disons. Dans un projet interne d’ingénierie, après évaluation, nous sommes arrivés à une deuxième architecture complètement différente pour le même problème et nous l’avons rédigée comme alternative documentée, avec les gates à franchir avant toute commande, au lieu de continuer sur la première simplement parce qu’elle avait déjà été commencée. Le coût d’un changement de direction à mi-parcours est inférieur à celui d’un système livré sous la mauvaise forme, et la différence est payée par le bénéficiaire dans les deux cas.

Quelle peut être l’ampleur du travail ?

D’un côté, un système avec trois applications et douze paquets communs dans un seul dépôt, 486 fichiers TypeScript, 68 fichiers de test et 151 commits, avec une base de données relationnelle, une coordination éphémère séparée de la source de vérité et des contrats communs entre applications. De l’autre, un système avec un seul processus et vingt points d’entrée, qui est exactement ce qu’il faut. L’ampleur n’est pas une promesse sur n’importe quelle taille — c’est l’observation que nous avons travaillé aux deux extrêmes.

Faites-vous aussi la maintenance après la livraison ?

Oui, mais dans le cadre d’un accord séparé, pas comme un implicite. Un système sur mesure a besoin de mises à jour de sécurité, du suivi des changements chez les fournisseurs externes et de quelqu’un qui regarde les journaux. Si vous préférez faire cela avec votre équipe, la remise est conçue pour le permettre. Si vous préférez que nous le fassions, nous écrivons ce que cela couvre et ce que cela ne couvre pas — y compris ce que signifie « urgent », car sans définition, ce mot ne veut rien dire.

Sur quoi reposent les affirmations ci-dessus (15 sources)

15 d'entre elles sont du code et des fichiers de nos dépôts. Nous n'en publions ni le nom ni la ligne : réunies sur une seule page, elles décriraient trop précisément comment sont construits des systèmes qui ne sont pas seulement les nôtres. Nous les parcourons avec vous, dans le dépôt, sur demande — la vérification reste possible, elle se fait simplement lors d'un échange.

Comment nous travaillons Tous les services

Qu'est-ce que vous voudriez voir mieux fonctionner ?

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.

Discutons