Sept systèmes, et ce qu’ils rendent impossible
Trois missions clients, un projet cofondé, trois bancs d’essai personnels. Chaque affirmation technique de ces pages a été confrontée au code source.
Ce qui ne relève pas du code — une date, un prix de concours, un avis — est donné comme tel, avec son auteur.
Un portfolio montre d’ordinaire des écrans. Une capture ne dit pas ce qui se passe quand deux entreprises clientes partagent une même base de données, ni ce que fait le système à trois heures du matin quand une clé de licence expire. Ces fiches montrent donc autre chose : trois règles par système, ce que chacune rend impossible, ce qu’elle ne couvre pas, et qui l’a posée.
Missions clients et projet cofondé
SFCTCV
Société savante de chirurgie thoracique et cardio-vasculaire. Depuis 2024, je conçois et développe l’interface de l’application de ses congrès — ce que l’utilisateur a sous les yeux : inscriptions, réservation d’hôtel, paiement, dépôt et notation des résumés scientifiques par les pairs. Mission toujours en cours.
Lire la fiche →
Dalya
Logiciel de facturation pour indépendants et petites entreprises françaises : devis, factures, avoirs, relances. L’enjeu tenait en une ligne — obtenir une facture à partir d’une phrase écrite en français, sans qu’un texte inventé par une intelligence artificielle devienne un document légal faux.
Lire la fiche →
Shareadesk
Projet entrepreneurial que j’ai cofondé, de novembre 2021 à septembre 2023, arrêté depuis. L’enjeu : faire tenir entre inconnus des règles d’argent et de confidentialité.
Lire la fiche →
Crealead
Coopérative d’entrepreneurs. Mission de conception de son portail interne. Le livrable est un prototype navigable et un langage visuel, destinés à être confrontés à de vrais membres avant tout développement. Aucune application déployée, aucun code livré — et c’est précisément l’intérêt de la mission.
Lire la fiche →Laboratoire de méthode
Trois projets personnels, qui restent des laboratoires. Un dispositif se propose à un client une fois qu’il a été construit, cassé et reconstruit plusieurs fois sur ses propres systèmes : ce que j’y éprouve à mes frais part ensuite en mission.
Laboratoire personnel. Aucun utilisateur en dehors de moi.Plume — encadrer des agents IA sur un code, par des règles écrites
Plume — encadrer des agents IA sur un code, par des règles écrites
Un environnement d’écriture longue assistée par IA. J’y travaille la question que rencontrent mes clients : faire contribuer des agents IA à un code sans que sa cohérence se dégrade, mois après mois.
Des règles, pas des conseils.
Les agents n’y reçoivent pas des recommandations mais des règles écrites, chacune avec trois choses : ce qu’elle interdit, l’incident qui l’a fait naître, et la commande qui prouve qu’on l’a respectée. Une règle sans sa commande de vérification est un vœu.
Un fichier de contrôles qui refuse les écarts.
Cinq cent trois lignes de contrôles relisent le code à chaque vérification. Ce n’est pas une revue assistée : c’est un refus. Le code qui franchit une règle n’avance pas.
Cinq fichiers régénérés et comparés à chaque vérification.
Produits automatiquement à partir du code — dont la description de l’interface du serveur — ils sont enregistrés dans le dépôt, puis régénérés et comparés. La moindre différence arrête tout. C’est ce qui empêche la documentation de mentir sans que personne s’en aperçoive.
Ce qui est écrit dans un document s’oublie. Ce que la machine vérifie se rappelle tout seul.
TypeScript, Node.js, PostgreSQL, agents IA sous contrainte écrite.
C’est le dispositif que j’installe en mission, transposé à votre dépôt et écrit à partir de vos incidents à vous — l’offre garde-fous.
Projet de recherche personnel. Aucune version publiée.Latitudes — une application dont la journée type ne dépend pas du réseau
Latitudes — une application dont la journée type ne dépend pas du réseau
Sa règle principale : ce que l’utilisateur y fait chaque jour ne doit jamais dépendre d’une connexion. Une règle facile à énoncer, et qui se perd à la première fonctionnalité ajoutée par quelqu’un de pressé.
Une quarantaine réseau nominative.
Dans l’application mobile, un seul dossier a le droit de parler au serveur, et exactement deux fichiers ont le droit de l’atteindre. La liste est nominative : ni un fichier de plus, ni un de moins.
Deux verrous indépendants, et pas un.
Cette liste est tenue par deux vérifications qui ne se connaissent pas : l’outil qui relit le code pendant qu’on l’écrit, et un test qui exige l’égalité exacte. Pourquoi deux plutôt qu’un ? Parce qu’un verrou unique se retire en une modification discrète. Deux verrous se retirent en se voyant.
Un paquet de langue unique, né d’un incident précis.
Une règle d’exploitation ne vient pas d’un guide de bonnes pratiques : elle est écrite après la panne, et formulée pour que la même panne ne puisse plus se rejouer sans être vue.
Ce qui n’est pas verrouillé
La décision de ne pas mettre d’IA dans le moteur qui compose la journée tient par la structure du code et par la relecture, pas par une vérification automatique. Je l’inscris noir sur blanc plutôt que de laisser croire l’inverse : toutes les règles ne peuvent pas être rendues mécaniques, et un inventaire honnête vaut mieux qu’une garantie approximative.
Un verrou unique se retire en une modification discrète. Deux verrous se retirent en se voyant.
TypeScript, React Native, Expo, SQLite.
Les frontières mécaniquement infranchissables et la documentation d’agents sont exactement ce que pose l’offre garde-fous.
Banc d’essai personnel. Jamais ouvert au public.CornerZ — tenir une fiche juste quand trois sources se contredisent
CornerZ — tenir une fiche juste quand trois sources se contredisent
Le sujet tient en une phrase : tenir une fiche juste quand trois sources automatiques se contredisent, et qu’un membre, lui, y était hier. C’est le problème que pose toute donnée agrégée — et celui que l’IA rend plus fréquent, pas moins.
La machine ne réécrit pas un humain.
Quand une source automatique contredit une saisie humaine, elle ne l’écrase pas : elle ouvre un arbitrage. La hiérarchie est posée dans le code, pas laissée à l’ordre d’arrivée des mises à jour.
La divergence est un objet, pas une erreur.
Trois sources qui ne disent pas la même chose ne produisent pas un échec : elles produisent une fiche marquée comme litigieuse, avec ce que chacune affirme. Écraser silencieusement au profit de la dernière serait le seul vrai bug.
L’écran d’arbitrage est le produit.
Le reste — l’agrégation, la normalisation — est de la plomberie. Ce qui se conçoit, c’est l’endroit où une personne tranche, et ce qu’on lui montre pour qu’elle tranche vite et bien.
Une donnée agrégée sans arbitrage explicite n’est pas une donnée : c’est la dernière source arrivée.
TypeScript, React Native, Node.js, PostgreSQL.
C’est la question que traite un audit quand un produit consomme plusieurs sources : où passe la frontière, et qui tranche.
- Diagnostic — 1 h, en visio, 200 € HT
- Audit — 3 jours, 2 400 € HT
- Garde-fous — 5 jours, 4 000 € HT
- Mission d’architecture — au jour, 800 € HT / jour
L’appel de trente minutes est gratuit et sans engagement. Il sert à savoir lequel de ces formats répond à votre situation — ou si aucun ne le fait.
Nous utilisons des cookies uniquement pour le bon fonctionnement du site. Avec votre accord, nous activons aussi le module de prise de rendez-vous Calendly, qui dépose ses propres cookies. Vous pouvez changer d’avis à tout moment depuis le pied de page. En savoir plus