Retour d'expérience
Du code à l'intention
Un an de workflow avec l'IA sur un projet open source
Notes de parcours sur un an de développement assisté par IA — avec les tâtonnements, les prises de conscience et les ajustements en cours de route.
01 — Le point de départ
Mai 2025. Je lance Ezkey, un projet MFA open source, en mode solo dev. Greenfield total. Tout est sur main, pas de branches, pas de tickets. L'objectif est simple : vélocité maximale.
Les assistants de codage IA sont encore jeunes. Ils n'ont pas le réflexe de faire un plan de travail, encore moins de le conserver d'une session à l'autre. Mais ils codent bien. Je prends confiance rapidement : l'IA génère du code Spring Boot fonctionnel, les tests passent, les entités JPA se mettent en place. La vélocité est réelle.
Ce que je n'ai pas encore réalisé, c'est que cette vitesse va me forcer à changer complètement ma façon de travailler.
02 — La prise de conscience documentaire
Très vite, je suis sidéré par la quantité d'information qui défile devant moi. L'IA produit du code, des analyses, des suggestions — et tout disparaît à la fin de la session. Je réalise que je perds de la valeur à chaque conversation.
De mon initiative, je commence à demander systématiquement une sauvegarde dans un fichier : plan de travail, analyse, décisions prises. C'est artisanal, mais ça fonctionne. Quelques mois plus tard, les agents de codage intègrent nativement le « mode plan ». Je garde l'habitude, mais elle se professionnalise.
Fast forward début 2026 : chaque feature commence par un plan de travail versionné. Quand le travail est complété, le plan est annoté puis archivé dans un dossier daté (par exemple .cursor/plans-archived-2026-03/). L'historique est préservé. Le feature et sa trace documentaire sont liés.
Ce dossier docs/ que j'avais presque négligé au début est devenu un corpus vivant. Je fais régulièrement des consolidations : je prends des fichiers d'analyse plus ou moins historiques, je demande à l'IA de les évaluer, de dispatcher l'information pertinente et de réduire le bruit. L'assistant de codage excelle dans ce rôle de bibliothécaire.
03 — Du trunk-based assumé aux worktrees
Pendant des mois, je me sens un peu coupable. Tout le monde fait des branches, des pull requests, des reviews. Moi, je pousse sur main. Pourtant, ça fonctionne. Le code compile, les tests passent, le projet avance vite.
Puis je tombe sur des équipes qui documentent ouvertement leur adoption du modèle trunk-based development. La culpabilité s'estompe. Mon workflow — conserver la vélocité avec un minimum de cérémonie Git — est un choix légitime, pas un raccourci.
Un peu plus tard, j'ajoute les worktrees Git. Le principe : trois répertoires de travail, chacun sur sa propre branche, mais tous synchronisés sur main. Le premier pour les analyses et la conception. Le deuxième pour l'application mobile. Le troisième pour les APIs backend.
L'intérêt est immédiat. Je peux faire une analyse conceptuelle sur un worktree pendant qu'un autre génère et teste du code. Les merges sont simples — souvent un fast-forward — parce que la stratégie reste trunk-based. Et c'est un outil de context switching propre : changer de sujet ne signifie plus « perdre le fil », le worktree conserve l'état complet.
04 — L'élévation progressive
Voici ce qui s'est passé, graduellement, sur un an :
Au début, je fais des prompts individuels. « Génère-moi un controller REST. » Je suis dans la couche basse : je produis du code.
Quelques semaines plus tard, je ne code plus. Je conçois. Je décris les entités, les relations, les flux — et l'IA génère l'implémentation. Mais je réalise que mes conceptions portent mes biais. Je remonte d'un cran vers l'analyse : je demande des alternatives, je compare avec des projets similaires, je fais évaluer les compromis.
Puis vient le changement le plus profond. Aujourd'hui, avant même de penser à l'analyse, je cadre l'intention. Qui va utiliser cette fonctionnalité ? Quel est leur quotidien ? Quel problème réel résout-on ? Et je le fais avec le corpus documentaire accumulé — PRD, analyses précédentes, plans archivés.
L'IA ancrée dans un corpus bien organisé devient un partenaire product owner. Elle connaît les entités, les contraintes, les décisions passées. La qualité du dialogue s'élève — et les décisions convergent plus vite.
05 — Libérer la pensée : la diction vocale
Novembre 2025. J'adopte un outil de diction vocale pour interagir avec l'assistant de codage. C'est un changement que je n'avais pas anticipé — et qui s'est révélé radical.
Quand on tape au clavier, on se censure. On économise les mots parce qu'écrire prend du temps, les mains fatiguent, et on finit par tronquer sa pensée. On donne un prompt minimal et on espère que l'IA devinera le reste. Souvent, elle devine mal — et on itère.
Quand on dicte, on pense à voix haute. La pensée coule librement d'un concept à l'autre. On ne cherche pas le mot exact — on exprime l'intention complète, avec son contexte, ses nuances, ses valeurs. Ce n'est pas de la surcharge de contexte : c'est du cadrage pertinent que nos doigts n'auraient jamais pris la peine de taper.
C'est directement lié aux valeurs de projet. Lorsqu'on peut énoncer librement l'ensemble des considérations pertinentes à un sujet — les contraintes, le contexte opérationnel, les principes à respecter — l'IA reçoit un cadrage d'une richesse incomparablement supérieure à ce qu'un prompt tapé aurait fourni. La qualité de ses réponses s'en ressent immédiatement.
Ce que j'ai découvert, c'est que la diction vocale est l'outil qui rend les niveaux supérieurs de la pyramide d'élévation véritablement accessibles. Donner l'intention, rappeler les valeurs, cadrer le contexte opérationnel — tout ça demande des mots, beaucoup de mots, et la voix les libère sans effort. C'est une fusion d'idées avec l'IA que le clavier seul ne permettait pas.
06 — L'intégrité conceptuelle à grande échelle
Au début, j'ai utilisé l'IA pour de l'intégrité technique : uniformiser les records Java, les enums, le nommage. Puis au niveau des designs : est-ce que tous les DTOs suivent le même pattern de mapping ? Est-ce que les réponses d'erreur sont cohérentes d'un module à l'autre ? L'IA évalue à travers la codebase et rapporte les écarts. Uniformiser un pattern transversal, c'est exactement ce qu'elle fait mieux qu'un humain.
Puis j'ai remonté encore. Activation, désactivation, révocation, suppression — ces concepts traversent toutes les entités d'Ezkey. Je les ai traités dans des plans de travail séparés, et ça a donné des comportements incohérents. Si on désactive un tenant, quel effet sur les enrôlements ? Sur les clés API ? Sur les intégrations ?
La révélation : le problème n'est pas chaque plan individuel — chacun fonctionne. Le problème, c'est l'absence de vision transversale. J'ai produit un document global, une analyse qui reprend l'ensemble des entités pour hiérarchiser et organiser les concepts de cycle de vie. Et l'IA, nourrie de ce corpus complet, a pu jouer un rôle de partenaire d'analyse de premier plan.
| Niveau d'intégrité | Exemple concret |
|---|---|
| Code | Uniformiser les records Java, les enums, le nommage |
| Design | Vérifier que les DTOs, mappers et réponses d'erreur suivent le même pattern |
| Analyse | Assurer la cohérence des cycles de vie à travers toutes les entités |
| Intention | Chaque décision de design est ancrée dans un besoin opérationnel réel |
07 — Les valeurs de projet comme boussole
Il y a un concept que je répète constamment dans Ezkey et qui mérite qu'on s'y attarde : les valeurs de projet. Ce ne sont pas des vœux pieux affichés dans un README. Ce sont des principes explicites, énoncés, répétés, et utilisés comme critères de décision à chaque niveau — code, conception, analyse, stratégie produit.
Pourquoi c'est si important avec l'IA ? Parce que l'IA a besoin de cadrage. Sans valeurs explicites, elle va optimiser selon ses propres biais statistiques. Avec des valeurs clairement énoncées, elle a un cap à suivre. Et moi aussi.
Voici les valeurs de projet d'Ezkey :
- Règle du 80/20. Viser 80 % de l'effet avec 20 % de l'effort. Constamment. À tous les niveaux. C'est un filtre implacable contre le gold plating et la sur-ingénierie.
- Pragmatisme. La solution la plus simple qui répond au besoin. Pas la plus élégante, pas la plus générique — la plus pragmatique.
- Complexité essentielle oui, complexité accidentelle non. La complexité qui sert directement l'objectif est acceptée. L'indirection inutile, l'abstraction prématurée, les couches supplémentaires « au cas où » — refusées.
- Eat your own dog food. Le système doit être autonome, intégré, cohérent. Pas de dépendance externe qu'on ne maîtrise pas. L'intégrité interne n'est pas un luxe — c'est un objectif de design.
- Suivre le consensus de la communauté. Pour chaque décision, se poser la question : qu'est-ce que les projets similaires font ? Qu'est-ce qu'un développeur qui arrive d'un autre produit va considérer normal et attendu ? Si la réponse est « mais qu'est-ce que c'est que cette affaire ? », c'est un signal d'alarme. Si c'est « ah oui, rien à redire, tout est clair », on est sur la bonne voie.
Ces valeurs sont répétées dans le corpus documentaire, et l'IA les intègre dans son cadrage. Quand je demande une analyse, l'IA sait déjà que la réponse doit être pragmatique, suivre le 80/20 et éviter la complexité accidentelle. Ça élimine énormément de bruit dans les échanges.
Et c'est aussi un outil de débiaisage. Quand je suis tenté par une solution trop sophistiquée, les valeurs me ramènent à l'essentiel. Quand l'IA propose quelque chose d'exotique, je peux lui rappeler : « Est-ce que c'est ce qu'on observe le plus souvent dans les projets comparables ? » La réponse recalibre instantanément.
08 — L'esprit critique comme compétence clé
À l'été 2025, comme beaucoup, je me suis senti un peu dépossédé. Quarante ans à écrire du code pour le plaisir de la chose, à maîtriser chaque subtilité de syntaxe. Regarder le code se produire sous mes yeux et me dire : « je ne fais plus rien. »
Puis la vélocité est devenue réelle. Et j'ai compris : l'enjeu n'est pas d'écrire le code — c'est d'en augmenter la qualité. Javadoc, tests unitaires, documents d'analyse : ce qui était des « bonnes pratiques optionnelles » est devenu une condition fondamentale pour que l'assistance IA reste fiable.
Mais le vrai changement a été d'apprendre à contenir mes propres biais. L'IA actuelle est un outil statistique avancé : elle oriente ses réponses selon les probabilités. Si je formule une question avec un biais, l'IA s'y enfonce. Si je demande que la sécurité soit le critère numéro un, les décisions seront radicalement différentes de celles où je priorise la performance. L'IA reflète et amplifie le cadrage qu'on lui donne.
Les stratégies que j'ai adoptées :
- Demander des alternatives. Jamais imposer une idée sans avoir vu les options. « Quelles sont les trois approches possibles ? Classe-les par compromis. »
- Demander des comparatifs. « Comment les projets similaires gèrent-ils ce problème ? » Ça ouvre un horizon de possibilités qu'on n'aurait pas envisagé seul.
- Ajuster mon vocabulaire. J'ai appris à formuler mes questions de façon plus neutre pour éviter de tilter l'IA dans une direction prédéterminée.
- Ne pas s'enfoncer. Dès qu'on sent l'escalation of commitment — on a investi dans une piste et on refuse de reculer — c'est le moment de redemander un état des lieux objectif.
On le vit trop facilement avec l'IA. Mais c'est aussi quelque chose qu'on devrait faire tous les jours, avec tout le monde. L'IA nous force simplement à améliorer une compétence qu'on négligeait : la rigueur dans notre propre pensée.
Je ne prétends pas y arriver à tout coup. Les biais sont tenaces, et il m'arrive encore régulièrement de me retrouver enfoncé dans une piste avant de réaliser que j'aurais dû reculer trois étapes plus tôt. Le simple fait de le savoir ne suffit pas — il faut le pratiquer, et c'est un exercice permanent.
09 — Le workflow actuel
Aujourd'hui, chaque initiative suit un cycle prévisible :
- Intention — Qui est l'utilisateur ? Quel est le besoin réel dans leur quotidien ?
- Analyse conceptuelle — Comment les entités du domaine interagissent pour accomplir cette intention ?
- Conception — Patterns connus, alternatives comparées, décisions documentées
- Génération de code — L'IA implémente, les tests valident
- QA et itération — Bugs conceptuels → recadrage design → boucle courte
La plupart du temps, le code fonctionne essentiellement du premier coup. Les problèmes résiduels sont des technicalités (traces, configuration) ou des limitations de design qu'on challenger en remontant au bon niveau.
Les worktrees permettent de faire tourner ce cycle en parallèle sur différents sujets. L'enjeu devient la gestion du switching cost et la capacité à évaluer les résultats.
Maîtriser le contexte
Plus on élève le jeu vers la conception et l'analyse, plus le contexte fourni à l'IA doit être pertinent — et plus il risque de devenir trop volumineux. J'ai appris à mes dépens que la surcharge de contexte dégrade la qualité des réponses autant que l'absence de contexte.
La stratégie qui a fait la différence : découper en verticales et chaîner les plans. Concrètement : quand je modifie un backend API, c'est un plan de travail dédié, centré sur cette verticale. Une fois le backend validé et testé, je génère la spécification OpenAPI mise à jour et je la dispatche dans les sous-projets — l'admin UI, le mobile. Chaque sous-projet démarre son propre plan, dans sa propre session, avec un contexte ciblé.
L'autre levier : les plans de travail versionnés deviennent un contexte condensé réutilisable. Au début d'un nouveau plan, il suffit de dire à l'IA : « va consulter le plan précédent ». Le plan archivé contient les décisions, les contraintes, les choix de design — déjà condensés. C'est un contexte ultra-pertinent avec un minimum de tokens. L'efficacité de la fenêtre de contexte est maximisée.
C'est un effet composé : chaque document bien écrit améliore la qualité de tous les échanges futurs, et chaque plan archivé devient un point d'entrée condensé pour la prochaine itération.
10 — Ce que j'en retiens
Ce que je décris ici, c'est un idéal vers lequel je tends — pas une réalité que je vis parfaitement chaque jour. Il y a des jours où je retombe dans le prompt rapide, où je néglige le plan, où je m'enfonce dans une piste sans la challenger. Le workflow « parfait » n'existe pas. Ce qui existe, c'est la direction.
L'IA ne remplace pas la pensée. Elle l'amplifie. La charge cognitive diminue côté code et augmente côté conception — et c'est exactement là qu'elle apporte le plus de valeur.
Le prérequis, c'est l'investissement dans le corpus documentaire. Plus on documente avec rigueur, plus le dialogue avec l'IA gagne en substance. C'est un cercle vertueux qui se capitalise à chaque itération.
L'antidote au risque de chambre d'écho, c'est un esprit critique aiguisé, ancré dans des valeurs de projet explicites. Rester objectif. Demander des alternatives. Accepter de se tromper et de reculer.
Je partage ces notes sans prétendre avoir trouvé la formule définitive. C'est un travail en cours — le projet évolue, les outils évoluent, et ma compréhension aussi. Si certaines de ces idées résonnent avec votre propre expérience, tant mieux. Si elles vous semblent incomplètes, c'est probablement le cas.
English: English version of this article
Voir aussi : Manifeste sur le codage assisté par IA
Voir aussi : Parallèle IA générative et No-Code / Low-Code