Le seul projet qui avait des utilisateurs

Vingt mois, cinq applications, et la découverte que ce que les gens adoptent n'est jamais ce qu'on a mis le plus de temps à construire.

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

Une brique posée avant les autres

Commençons par une confession de chronologie.

Cette brique-là n'est pas la dernière posée. C'est la première. Elle court de septembre 2024 à avril 2026, bien avant l'Auditeur de code, bien avant les démonstrateurs médicaux. Si elle arrive en quatrième position dans cette série, c'est parce qu'elle explique les trois autres : les questions que je me suis posées ensuite, seul devant un écran, sont toutes nées ici, devant des gens.

Vingt mois en alternance auprès d'un acteur des médias et du marketing B2B, en lien direct avec la direction générale. Cinq applications, des premières expérimentations jusqu'à des outils que des équipes ouvrent le matin. Et une chose que ni un démonstrateur, ni un dépôt GitHub, ni le meilleur des articles de blog ne peut vous enseigner : ce qui se passe quand quelqu'un d'autre que vous doit s'en servir.

Ce que j'ai apporté n'était pas technique

Avant l'IA, j'ai été contrôleur interne, puis inspecteur en banque. Un métier dont le cœur consiste à entrer dans un service qu'on ne connaît pas, à comprendre en quelques jours comment le travail s'y fait réellement, et à repérer l'écart entre la procédure écrite et la pratique.

Je pensais avoir changé de métier. En réalité, j'ai gardé le premier geste et changé d'outil.

Parce que la première phase d'un projet IA, ce n'est pas du développement. C'est un audit de processus qui ne dit pas son nom. Comment ce travail se fait-il aujourd'hui, étape par étape ? Qui produit quoi, à partir de quelle information, et sous quelle forme ? Qu'est-ce qui existe déjà dans les applications en production, et pourquoi personne ne s'en sert ? Où sont les incohérences entre ce qu'on m'explique en réunion et ce que je vois à l'écran ?

Ces questions-là, un inspecteur les pose par réflexe. Elles ont plus fait pour la réussite de ces projets que n'importe quel choix d'architecture.

Et elles ne se posent pas une fois, dans un cahier des charges signé au démarrage. Elles se reposent à chaque itération. Les développements se sont ajustés discussion après discussion, en montrant, en écoutant l'objection, en revenant. Le besoin réel des utilisateurs n'était presque jamais celui exprimé au premier rendez-vous - non par mauvaise foi, mais parce qu'on décrit mal ce qu'on fait tous les jours sans y penser.

Je me souviens du moment exact où j'ai su que cette méthode payait.

Sur l'une des applications, j'avais enchaîné les entretiens pendant des semaines : plusieurs personnes, plusieurs services, la même question posée sous des angles différents jusqu'à reconstituer le processus réel. Puis est venu le moment de faire tester l'outil. La personne désignée comme pilote l'ouvre, l'utilise quelques minutes, et lâche, amusée :

« C'est marrant, ça correspond exactement à ce que l'on fait. »

Elle l'a dit comme on note une coïncidence. Je l'ai reçu comme le meilleur retour possible.

Parce que c'est exactement ce qu'on cherche. Pas « c'est impressionnant », pas « je n'aurais jamais cru que l'IA sache faire ça » - ces phrases-là font plaisir et ne prédisent rien. Mais « ça correspond à ce que l'on fait », cela signifie qu'il n'y aura rien à expliquer, rien à réapprendre, aucune procédure à réécrire. L'outil s'insère dans le travail au lieu de demander au travail de s'insérer dans l'outil.

Cette phrase n'était pas une coïncidence. C'était le produit de toutes les conversations qui l'avaient précédée.

La leçon qui m'a le plus surpris

Voici le constat que je n'attendais pas, et qui a changé ma façon de travailler.

Les applications les plus vite adoptées n'ont pas été celles sur lesquelles j'avais passé le plus de temps.

Aucune corrélation. Zéro. Certaines m'ont coûté des semaines de conception, d'ajustements fins, de soin dans les détails - et sont restées tièdes. D'autres, plus simples, ont trouvé leur public en quelques jours.

Le facteur commun des secondes est d'une banalité désarmante : elles réglaient une tâche pénible. Pas une tâche importante, pas une tâche stratégique. Une tâche que les gens détestent faire.

Générer du contenu à partir de documents PDF ou d'enregistrements réalisés de façon systématique, par exemple. Personne n'a eu besoin qu'on la vende, cette application. Le gain de temps était immédiat, visible, et surtout il portait sur le genre de travail que personne ne réclame en arrivant le matin. L'adoption n'a demandé aucun effort de conviction. Elle a demandé que l'outil existe.

Il y a une seconde famille de succès, plus rare et plus satisfaisante : l'application qui fait ce qu'aucune autre ressource ne sait faire. Pas plus vite - mieux. Plus précise, de meilleurs résultats, sur un besoin où l'existant décevait. Celle-là aussi a été adoptée rapidement, et pour une raison différente : elle ne remplaçait pas un travail, elle rendait possible quelque chose qui ne l'était pas.

Retenez la règle, elle vaut pour vos propres arbitrages : on n'achète pas l'adoption avec de l'effort de développement. On l'obtient en visant juste. Le temps que vous passez sur le choix du cas d'usage rapporte davantage que le temps que vous passerez à le peaufiner.

Le projet qui m'a le plus appris est celui que personne n'a utilisé

Il faut parler de celui-là, parce que c'est le plus instructif de tous.

L'idée était excellente sur le papier : automatiser la production de comptes rendus de briefs clients. Un besoin réel, une tâche chronophage, un consensus immédiat en réunion. Techniquement, rien d'insurmontable - et de fait, l'application a été construite et déployée. Elle fonctionnait.

Elle n'a pas servi. Les briefs se déroulaient à l'oral, dans des échanges, et ne laissaient pas de trace systématique. On ne peut pas résumer ce qui n'a pas été capté : l'outil attendait une matière première que le processus ne produisait pas.

Ce n'est le tort de personne. C'est même parfaitement normal : ces échanges avaient toujours fonctionné ainsi, et rien n'imposait de les enregistrer tant qu'aucun outil n'en avait l'usage. La matière première n'existait pas encore, tout simplement parce que le besoin de matière première est né avec le projet.

Mais la leçon est structurante, et je la répète désormais à chaque démarrage : avant de se demander si une IA sait faire quelque chose, il faut vérifier que l'information dont elle a besoin existe, sous une forme durable et accessible. L'ordre de ces deux vérifications décide de plusieurs semaines de travail.

Remarquez d'ailleurs le contraste avec les applications adoptées. Elles partaient de PDF, ou d'enregistrements réalisés de façon systématique. Autrement dit : de matière première déjà là. Ce n'était pas un hasard, c'était la condition.

C'est de ce constat qu'est née, deux ans plus tard, ma curiosité pour l'interopérabilité et les formats d'échange - le sujet de l'épisode 3. La question « à quoi peut-on brancher ce système ? » n'est pas une question technique. C'est la question qui décide si le projet existe.

Ce qui reste après

L'alternance s'est achevée avec l'obtention de mon diplôme, au printemps 2026. Une fin prévue de longue date, connue de tous dès le premier jour, ce qui est probablement la meilleure des configurations : on construit différemment quand on sait qu'on ne sera pas là pour maintenir.

Concrètement, cela veut dire des applications autonomes, mises entre les mains des équipes plutôt que rattachées à leur auteur. Le critère de fin de mission n'était pas « ça marche », c'était « ça marche sans moi ».

Je crois que c'est la seule définition honnête de la réussite dans ce métier. Un système qui dépend de la présence de celui qui l'a construit n'est pas livré. Il est prêté.

Le mot de la fin

Trois démonstrateurs racontent ce que je sais construire. Celui-ci raconte autre chose, et c'est pour cela qu'il devait figurer dans cette série : ce que je sais faire quand il y a des gens en face.

Écouter comment le travail se fait vraiment. Repérer l'écart entre ce qu'on me décrit et ce que je constate. Comprendre une organisation avant de proposer quoi que ce soit. Accepter qu'un bon projet meure parce que sa matière première n'existe pas, et le dire tôt plutôt que tard. Viser les tâches pénibles avant les tâches nobles. Partir en laissant l'outil debout.

Rien de tout cela n'est de l'intelligence artificielle. C'est ce qui décide de son sort.

Et cela m'amène à la question qu'on me pose toujours en premier rendez-vous, celle du modèle à choisir. Vous devinez ce que j'en pense maintenant.

C'est l'épisode 5.

📖 Dans la même série - Épisode 1 : l'Auditeur de code (décrire la qualité avant de la produire) · É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 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