Mon premier projet ne construit rien

Il regarde du code déjà écrit, en mesure l'état, et dit par quoi commencer. Voici pourquoi j'ai posé cette brique en premier.

Série « Brique après brique », Épisode 1/5 · 2. La recherche documentée · 3. La passerelle FHIR · 4. ITFacto · 5. Le modèle est la dernière question

Un mur ne se monte pas dans le désordre

Chaque brique porte la suivante. Une brique posée trop tôt ne tient sur rien, et le problème n'est pas qu'elle s'écroule : c'est qu'elle ne s'écroule pas tout de suite.

On construit les systèmes d'IA exactement comme ça, sauf qu'on l'oublie. La question qu'on me pose en premier est toujours la même : quel modèle. Elle arrive trois briques trop tôt.

Cette série raconte trois démonstrateurs, une mission de vingt mois en entreprise, et surtout l'ordre dans lequel je les ai posés. Commençons par la première brique, celle qui surprend le plus : mon premier projet ne construit rien du tout.

La compétence qui vient de changer de camp

Écrire du code n'a jamais été aussi facile. En 2026, un développeur assisté produit en une journée ce qui lui prenait une semaine, et un débutant obtient en trois minutes quelque chose qui compile, qui tourne, et qui a l'air correct.

C'est cette dernière partie qui devrait nous occuper. Qui a l'air correct.

La rareté s'est déplacée. Elle n'est plus dans la production, elle est dans la lecture. Savoir ouvrir un dépôt qu'on n'a pas écrit, en quelques minutes, et dire où ça pèche, ce qui va coûter cher dans six mois, et par quoi il faudrait commencer. Cette compétence-là ne s'est pas automatisée, et la demande a explosé au rythme exact où le code se met à pleuvoir.

Voilà pourquoi mon premier outil est un outil qui regarde. On lui donne un identifiant GitHub, il parcourt les dépôts publics, il mesure, et il envoie un rapport. Il n'exécute jamais le code. Il ne touche à rien de privé. Il ne produit pas une ligne. Il analyse et il propose.

Tout le monde sait dire « du bon code », personne ne sait le définir

Faites l'expérience en réunion d'équipe. Demandez ce qu'est un code bien construit. Vous obtiendrez cinq réponses, toutes sincères, toutes différentes, et aucune écrite nulle part.

Pour l'un ce sera la lisibilité. Pour l'autre les tests. Pour un troisième, la simplicité, notion sur laquelle personne ne s'accorde non plus. Et si vous demandez de comparer deux dépôts, vous récolterez des impressions, pas des arguments.

Or on ne peut pas améliorer ce qu'on ne sait pas décrire. C'est vrai du code, c'est vrai de tout le reste, et c'est précisément le mur contre lequel butent la plupart des projets qui veulent « améliorer la qualité » de quoi que ce soit.

Alors mon vrai premier travail n'a pas été de développer. Il a été d'écrire ma définition, en six axes que j'assume comme une prise de position :

La structure et la lisibilité. Complexité, duplication, taille des fichiers, organisation.
La sécurité. Secrets exposés dans l'historique, vulnérabilités décelables par analyse statique.
La maîtrise de la dette. Où se concentrent les modifications, et ces fichiers que tout le monde évite de toucher.
Le rythme et la curation. Granularité des commits, fichiers générés commités par mégarde, hygiène de l'historique.
Les tests. Leur présence, leur intégration continue, la part de code réellement couverte.
Les dépendances. Manifeste présent, versions verrouillées.

Six axes, c'est peu. C'est volontaire. Une grille qu'on ne peut pas retenir n'est pas une grille, c'est un formulaire, et un formulaire ne change le comportement de personne.

Et ces six axes sont discutables. Quelqu'un peut légitimement en contester la pondération. Tant mieux : une définition qu'on peut contester est une définition qui existe. C'est déjà infiniment plus qu'une impression.

Une note qui change d'un jour à l'autre n'est pas une note

Ici se trouve la difficulté que je ne voyais pas venir, et qui a occupé le plus clair du projet.

Demandez à un modèle de langage de noter un dépôt sur cent. Il vous donnera un chiffre. Redemandez-lui le lendemain, sur le même dépôt : le chiffre aura bougé. Demandez-lui de comparer deux projets qu'il a notés séparément, et vous découvrirez que les deux notes n'étaient pas sur la même échelle.

Ce n'est pas un défaut de modèle, c'est une propriété. Un jugement sans référence est une opinion élégamment formulée.

D'où deux principes de construction. D'abord, mesurer avant d'interpréter : les métriques objectives sont calculées, pas devinées, et l'IA intervient ensuite, pour expliquer et hiérarchiser. Ensuite, calibrer la note sur un corpus de référence, de façon qu'un score signifie quelque chose par rapport à des dépôts comparables, et non par rapport à l'humeur d'une exécution.

Ce corpus, il a fallu le construire. 2 784 dépôts publics mesurés, échantillonnés par strates : sept langages, quatre tranches de popularité - dont celle des projets à moins de dix étoiles, pour ne pas calibrer sur l'élite - et plusieurs fenêtres d'activité, avec un minimum de trente dépôts par strate sous peine de fusion avec la strate parente.

Le décompte varie d'une métrique à l'autre, de 2 245 à 2 784, et ce n'est pas un défaut de collecte : une métrique ne compte que là où elle a une surface. Un dépôt sans test n'a pas un mauvais taux de couverture, il n'en a pas. Confondre les deux reviendrait à sanctionner l'absence de matière comme un défaut de qualité.

Une note n'est donc pas comparée à un seuil décidé par moi. Elle est comparée à un percentile : votre position parmi des projets qui vous ressemblent. C'est le seul moyen d'obtenir un score qui discrimine au lieu de flatter tout le monde à 72 sur 100.

Un chiffre qu'on ne peut pas justifier à quelqu'un qui n'est pas d'accord ne vaut rien. J'ai passé des années, dans une vie professionnelle antérieure, à devoir défendre des constats devant des gens que mes conclusions n'arrangeaient pas. On y apprend vite qu'une évaluation ne tient que par sa méthode.

Constater ne suffit pas

Un audit qui se contente de lister ce qui ne va pas produit un effet parfaitement identifié : on le lit, on se sent mal, on ne fait rien.

C'est pour ça que l'outil ne s'arrête pas à la mesure. Il trie. Les recommandations sortent classées par impact et par effort, avec une action concrète pour chacune, parce que la seule question qui compte quand on hérite d'un projet imparfait n'est pas « qu'est-ce qui ne va pas », c'est « par quoi je commence lundi ».

Et le rapport dit aussi ce qui va bien. Une synthèse des points forts récurrents, formulée sans flagornerie. Ce n'est pas de la politesse : on ne consolide pas ce qu'on n'a pas identifié, et un développeur qui ignore ce qu'il fait bien le perdra à la prochaine refonte.

La différence tient en un mot. Un outil qui juge classe les gens. Un outil qui analyse et propose leur donne une prise. Seul le second sert à quelque chose.

Ce que cette brique portait

Je n'avais pas prévu de commencer par là. J'ai commencé par là parce que je ne pouvais pas faire autrement.

Les systèmes que j'allais construire ensuite reposaient tous sur une promesse de fiabilité. Or je n'avais aucun moyen d'étayer cette promesse tant que je n'avais pas écrit ce que fiable voulait dire, ni de quoi le mesurer. J'aurais demandé qu'on me croie sur parole. C'est exactement ce que je reproche aux démonstrations qui impressionnent et ne prouvent rien.

L'Auditeur a d'abord servi contre moi-même. Mes propres dépôts sont passés dessous, et ce n'était pas confortable.

Voilà la brique, et elle vaut bien au-delà du code :

On ne construit pas fiable tant qu'on n'a pas écrit, noir sur blanc et de façon mesurable, ce que fiable veut dire.

Transposez-la à n'importe quel projet. Comment saurons-nous que ce système marche ? Si personne ne sait répondre au démarrage, personne ne saura répondre à la livraison non plus. On se contentera d'un avis, généralement celui de la personne la plus convaincante dans la pièce.

Le mot de la fin

Cette première brique n'était qu'un étalon. Un étalon ne sert à rien tant qu'on ne mesure rien avec.

Restait donc à construire quelque chose sous mes propres critères, et à le faire sur le terrain le plus exigeant que je connaisse : un domaine où une réponse fausse mais plausible fait plus de dégâts qu'une absence de réponse.

C'est l'épisode 2.

📖 Dans la même série - Épisode 2 : la recherche documentée (une réponse qui cite ses sources, ou qui se tait) · Épisode 3 : la passerelle FHIR (brancher la connaissance sur le réel) · Épisode 4 : ITFacto (vingt mois, cinq applications, des utilisateurs) · Épisode 5 : le modèle est la dernière question (les quatre questions du premier rendez-vous).

Les trois systèmes évoqués dans cette série sont en ligne et publics. Je conçois des systèmes d'IA traçables et vérifiables, du cas d'usage au déploiement - en savoir plus sur mon parcours, ou écrire à contact@lamoulinette.ai.

← Retour au blog