Bilan

Bilan & posture (2022 → mi‑nov. 2025)

Ce journal raconte trois ans où j’ai mis les IA au cœur de mon travail, parfois de façon très intensive. Avec le recul, il en ressort surtout des convictions et une posture : ce que je garde, ce que j’abandonne, et la manière dont j’ai envie de travailler avec ces outils.

Qualité des modèles et des données

Une conviction simple : la qualité des sorties est plafonnée par la qualité des données d’entraînement. Quand le code public est moyen, la moyenne d’un modèle l’est aussi. Un modèle “puissant” ne suffit pas. Pour obtenir quelque chose de propre, il faut des règles explicites, un contexte bien cadré, et des tests sérieux.

Je reste méfiant vis‑à‑vis des modes superficielles (emojis, ton “trop humain”, storytelling gratuit). Ce qui m’intéresse, c’est ce qu’on peut refaire demain dans un autre projet, pas seulement la démo du jour.

Ma posture de chef d’orchestre

Au départ, mon plaisir, c’était de “bouffer du code”. Aujourd’hui, je me vois surtout comme un chef d’orchestre : quelqu’un qui conçoit les systèmes dans lesquels les IA vont travailler.

Concrètement, je passe plus de temps à :

• définir des règles et des contrats que le code doit respecter ;
• écrire des tests et des checks qui servent de garde‑fous ;
• concevoir des architectures de flux (contexte, agents, CI) ;
• automatiser la collecte et la synthèse du contexte plutôt que de le recopier à la main.

Le développeur reste critique et décisionnaire. L’IA est pour moi un amplificateur de pensée : elle accélère quand le cadre est clair, elle dérive quand il ne l’est pas. Le prompt engineering moderne, c’est moins une phrase magique qu’un environnement bien préparé.

C’est aussi un outil d’exploration temporelle : je teste plus d’idées plus vite, j’échoue plus tôt, j’apprends plus vite.

Échecs assumés & ce que j’abandonne

Ce que je garde de mes échecs, ce n’est pas la honte, c’est la liste de ce que je ne veux plus refaire. Je ne parle pas de tout ici, mais voici les abandons marquants :

• Scan exhaustif local : trop lent, coût exponentiel. Je préfère l’indexation sélective et l’accès à la demande.
• Fichiers de contexte maintenus à la main : impasse (c’était délégué aux IA, mais quand même trop lourd). Il faut générer et nettoyer automatiquement dès que l’arbre change.
• Sur‑ingénierie d’orchestration : trop de sous‑commandes, de scripts, de cérémonies finissent par coûter plus cher que ce que ça apporte. KISS et YAGNI ne sont pas des slogans, ce sont des garde‑fous.
• Prompts magiques sans architecture : “plus de prompts” ne compense pas l’absence de structure. Je vise désormais “plus d’architecture, moins de prompts”.
• Règles non testables : une intuition qui ne se traduit pas en règle vérifiable (lint, check, test) finit souvent par disparaître. Si je peux l’automatiser, je l’automatise.

Ces abandons ne sont pas des renoncements ; ce sont des choix de design pour les cycles suivants.

Travailler avec moi sur ces sujets

Si tu es arrivé jusqu’ici, il y a des chances que ces sujets t’intéressent aussi. Voici quelques exemples de collaborations qui m’attirent (mais je reste ouvert à d’autres approches, tant qu’on parle de système et de qualité) :

• Mettre des rails IA dans un projet existant : clarifier le contexte, brancher la CI, dessiner un workflow d’orchestration simple mais robuste.
• Auditer / consolider un setup IA : regarder ce qui existe (prompts, scripts, agents, CI), identifier les sur‑ingénieries, simplifier, documenter une nouvelle version plus claire.
• Co‑construire des outils ou workflows open source autour du contexte, des MCP (puissants mais lourds en contexte), de l’orchestration et de la qualité.
• Former ou accompagner une équipe sur l’usage “sérieux” des LLM en dev : comment déléguer sans lâcher le volant, comment transformer les intuitions en règles et en tests.

Si tu veux en discuter, le plus simple est de partir d’un problème concret (un projet, un workflow, une équipe) et de voir comment ces idées peuvent t’être utiles. Pas de pitch commercial, juste du terrain.

Conclusion

Le cœur de mon expérience : l’IA amplifie la pensée qui la pilote. L’enjeu n’est pas de laisser l’IA écrire à notre place, mais de penser avec elle : concevoir des règles, des flux et des garde‑fous pour la rendre utile, répétable et sûre.

Je veux partager ça parce que c’est concret, et parce que le basculement est net : du développeur qui tape du code au chef d’orchestre qui dessine des systèmes. La suite sera probablement un autre cycle : moins d’expérimentation, plus de stabilisation et de transmission.