Retour d'expérience collectif sur une journée passée à confronter le discours « AI-Driven Development » à la réalité du delivery.
Le 5 juin 2026, la communauté Tech s'est réunie à La Cité des Congrès de Nantes pour TechReady 2026, journée placée sous le triptyque « Cloud, AI, Innovation ». Ippon Technologies y était partenaire et présent sur scène.
Une même question traversait presque tous les talks : maintenant que l'IA s'invite dans tout le cycle de fabrication du logiciel, qu'est-ce qui reste à notre main ? Notre retour d'expérience tient en cinq idées.
1. L'IA déplace le métier vers la conception, pas vers le code
La keynote d'ouverture (Alexandre Soyer, Manifeste AI-Driven Development) donnait le ton avec une promesse forte : des équipes « 4,78× plus rapides, sans perte de qualité ». Mais l'idée qui compte dépasse l'annonce. Le rôle ne se réduit plus à produire du code ligne à ligne : il glisse vers la conception, l'architecture, puis la construction et la maintenance de l'outillage IA lui-même. Github : https://github.com/ai-driven-dev/manifest.
Ce glissement ne touche pas que les développeur·ses.. Les équipes produit, data et infrastructure se repositionnent de la même façon, du faire vers le concevoir et piloter.
Deux sessions ont montré que la promesse tient sur des cas concrets : l'orchestration multi-agents pour automatiser des migrations techniques sur un patrimoine de dix ans (Zenika), et la construction d'une landing zone Scaleway déployée à 100 % par des agents (Onepoint). Le point commun : l'effort se déplace vers la conception du système qui produit le logiciel, plus que vers l'écriture du logiciel.
2. Garder la main sur les agents de code : une affaire de méthode, pas d'outil
Passer de la démo à une pratique d'équipe tenable repose sur quelques principes que deux sessions (table ronde « Adoption des agents de code » ; « Craft-Driven AI » d'OCTO) faisaient converger. Un retour de terrain marquant donnait l'échelle : de l'ordre de 500 pull requests pour 10 développeur·ses en une semaine (à ne pas lire comme une moyenne de marché toutefois). Les conditions de réussite, elles, sont transposables :
- garder le merge manuel et la revue humaine sur les parties critiques ;
- investir dans l'agent de revue (le plus exigeant) et corriger l'agent quand on corrige sa pull request ;
- embarquer un agent comme un·e nouveau·elle développeur·se : documentation soignée, agents spécialisés par couche, exemples de code ;
- assumer qu'une part importante du temps (30 à 40 % cités) soit investie dans la mise à jour des pratiques, tant tout évolue vite.
La posture qui résume tout : l'agent aide, l'humain décide.
3. L'IA est un amplificateur, pas un accélérateur
Une des sessions les plus stimulantes (Arthur Magne, Packmind) prenait l'enthousiasme à rebours : malgré une forte hausse de l'usage de l'IA, le débit de pull requests ne progresse que faiblement. Une des explications : le codage ne pèse qu'une fraction de la journée (environ 14 % cités). Optimiser cette fraction ne sert à rien si le goulet d'étranglement est ailleurs, et accélérer la production tend à dégrader la stabilité.
D'où la thèse que nous partageons : l'IA est un amplificateur. Sur de bonnes bases de delivery, on y gagne ; sur des bases fragiles, on amplifie les problèmes, et les écarts se creusent entre équipes. Deux leviers pour rester aux commandes :
- le context engineering : fournir un contexte épuré et rigoureux pour que l'IA atteigne ses objectifs et produise de la qualité devient une véritable discipline ;
- le harness engineering : un agent se résume à `modèle + harness`. Le modèle est une boîte noire fournie par un tiers ; le harness (contexte, exécution, validation, garde-fous) est propre à l'équipe et concentre désormais la valeur.
Conséquence partagée avec la keynote : le·la développeur·se devient System Engineer, plus proche du Produit et du Métier, et investi·e dans le mentorat des juniors. Côté sécurité, même exigence : l'IA tend toujours à répondre, parfois au détriment de la sécurité, ce qui fait du moindre privilège un prérequis, pas une option.
4. L'optimisation du coût de l'IA devient une discipline
Nouvelle capacité, nouveaux coûts à piloter. Deux sessions (« Tokens : le nouveau cloud waste » ; panel « ROI de l'IA en 2026 ») posaient le même constat : le token est la nouvelle source de gaspillage, et personne ne la réduira à notre place. Ce qui ressort :
- la sobriété est à notre main : contexte concis, documentation à jour, serveurs MCP inutiles coupés, outillage dédié (projets open source cités : Caveman, RTK) ;
- le ROI se mesure en qualité plus qu'en volume, ce qui suppose des KPI à jour pour le mesurer réellement ;
- le modèle de prix des tokens reste aux mains des fournisseurs : d'où l'importance d'investir dans la flexibilité des fournisseurs (éviter le vendor lock-in) et de gérer un parc de modèles selon les usages, jusqu'aux petits modèles (SLM) hébergés en local.
Une question, restée ouverte, donne la mesure de l'enjeu : le coût des tokens dépassera-t-il celui des salaires ? D'où l'hypothèse, à demi sérieuse, d'un métier de token FinOps.
5. L'IA en entreprise dépasse largement les LLM et le code
Mettre un modèle en production est une chose, le rendre fiable et utile en est une autre. Et l'IA crée de la valeur bien au-delà du code, comme l'ont illustré plusieurs retours d'expérience :
- La Poste / Thales : le tri et la distribution du courrier n’ont pas attendu les LLM pour utiliser l’IA, et ce talk nous rappelle qu’ils n’en sont pas l’unique facette. L'IA on-premise reste également possible, mais la portabilité a un coût caché (le GPU peut influer sur le comportement du modèle). Dans tous les cas, le MLOps doit être solide (incidents non déterministes, réentraînement) pour rester réactif sur les problèmes en production ;
- Ippon × Sodebo : contrôler la qualité des salades en production par computer vision. Encore une fois, l'IA en entreprise ne se résume pas aux LLM : elle peut permettre de mieux maîtriser la qualité d'une chaîne industrielle et éviter les pertes ;
- Peaksys / Cdiscount : l'IA prend en charge les analyses chronophages du Product Manager pour le recentrer sur sa vision stratégique ;
- Sercel : de fournisseur de matériel à vendeur de services d'analyse de données, l'IA peut aider à modifier un modèle d'affaires entier.
6. L'humain reste responsable de ce que l'IA produit
La table ronde sur la souveraineté de l'IA (avec notamment Digital4Better & Fruggr, Reply, Scaleway) déplaçait le regard vers l'impact : l'empreinte environnementale et sociale devrait être intégrée dès la conception des modèles. La consommation d'eau et d'électricité du numérique, déjà significative, est sur une trajectoire de forte croissance (x25 annoncé). La mise en perspective assumée (il n'y a pas de progrès sans impact, comme la roue ou le feu en leur temps) ne dilue pas la responsabilité : l'humain reste responsable de ce que l'IA produit.
Ce que nous retenons :
1. L'IA ne remplace pas nos métiers, elle les transforme. Le·la développeur·se devient System Engineer : il·elle orchestre et se porte garant·e des bonnes pratiques de code, plus que du code lui-même. Le·la Product Manager se recentre sur la stratégie, assisté·e par l'IA qui prépare le travail d'analyse.
2. Nous restons responsables de ce que nous produisons avec l'IA. Code, infrastructure ou décision : il faut comprendre et contrôler ce qu'elle génère.
3. Nous avons un rôle à jouer dans la sobriété, en réduisant notre consommation de tokens.
4. Les agents ont des « limites cognitives ». Leur contexte est borné : documentation claire et épurée, découpage et spécialisation des tâches restent pertinentes, comme pour un cerveau humain.
5. Une évolution constante et rapide. En moins de deux ans, on est passé du prompt en douce dans VS Code à des pipelines de génération de code en production chez des clients grands comptes. Ce qui relevait de l'expérimentation en 2023 est aujourd'hui une réalité opérationnelle, et le rythme ne faiblit pas : chaque trimestre redéfinit ce qu'on croyait stabilisé.
En un mot : l'AI-Driven Development tient ses promesses quand les fondamentaux d'ingénierie sont là. Le vrai chantier n'est pas d'apprendre à l'IA à coder, c'est d'apprendre à concevoir, encadrer et valider les systèmes qui la mettent au travail.
