RETEX : l'IA dans le delivery d'un projet réel

On parle souvent de l’IA dans le développement logiciel comme si elle remplaçait d’un coup une partie entière de l’équipe. C’est une façon très simpliste de voir le sujet.

Sur un projet réel, avec des enjeux business concrets, un cahier des charges précis et des arbitrages nécessaires, l’IA ne fait pas disparaître l’humain. Elle l’augmente à plusieurs niveaux, comme le montre le retour d’expérience suivant.

Fiche d’identité du projet

Le projet est typique d’un développement web moderne et exigeant.

Autrement dit : pas un POC mais un projet conséquent.

‍

Avant-propos : les limites de l’IA quand les contraintes organisationnelles sont fortes

La différence entre le vibe coding et le développement de produit dans des organisations réelles est réelle. Il n’est pas possible d’utiliser des IA autonomes et non contrôlées. Les accès aux données sont restreints, toujours supervisés. Les garde-fous sont nombreux : dans notre cas, certaines API sont désactivées, les branchements directs sur des systèmes internes sont interdits, et la 2FA est obligatoire pour tout type d’accès. Ainsi, l’IA, tout comme les humains, est tributaire de ces règles du jeu. Elle ne peut exprimer son potentiel que dans le cadre strict qu’on lui propose.

La multitude d’acteurs et la nécessité de maîtriser le delivery impliquent aussi des échanges transactionnels obligatoires, par exemple :

• un designer livre une maquette qu’un product manager validera et transformera en ticket.
• un développeur livre une fonctionnalité qu’un QA validera avant la release.
• un product manager définit des critères d’acceptation qu’un QA utilisera pour valider ou refuser la livraison.

Ainsi, il est important de préciser que, dans ce cadre, une IA ne peut pas produire directement un résultat final, comme dans l’image idéale du vibe coding. Lorsque les contraintes organisationnelles sont fortes, une IA ne peut produire qu’un résultat partiel, limité à la portée de l’acteur qu’elle accompagne, lui-même limité par le cadre de son rôle et de ses responsabilités.

Côté product : mieux préparer, mieux transmettre

Sur la partie product, l’IA sert d’abord à accélérer la production de matière écrite.

Elle aide à rédiger et relire des tickets, reformuler des critères d’acceptation, préparer des comptes rendus, synthétiser des échanges, produire des changelogs lors des releases ou générer des rapports QA exploitables par l’équipe.

Ce ne sont pas des tâches accessoires. Dans un projet de plusieurs mois, la qualité de transmission devient un sujet central. Un ticket flou sera mal implémenté, coûtera cher à corriger. Une décision mal documentée revient trois semaines plus tard sous forme de bug, de débat ou de reprise.

L’intérêt de l’IA ici n’est pas de décider à la place du product manager : c’est de le rendre plus précis.

Côté tech : produire, vérifier, expliquer

Sur la partie technique, l’usage est plus visible. Les équipes s’appuient sur des agents de code pour préparer et réaliser les développements :

• création de plans de développement à partir des tickets ;
• implémentation de fonctionnalités frontend et backend ;
• rédaction de tests unitaires et end-to-end ;
• correction d’alertes de sécurité remontées par Azure CodeQL ;
• contrôle qualité en fin de ticket sur la base des critères d’acceptation ;
• première passe de revue de code sur les pull requests ;
• explication de zones complexes du code.

Côté ops, l’IA aide à produire de l’infrastructure as code, dans le cas présent sous forme de code Terraform.

Après 8 mois de développement, le projet compte plus de 2 000 tests automatisés, dont 300 tests end-to-end couvrant des parcours utilisateurs. L’IA rend la discipline d’écriture des tests plus accessible au quotidien.

Sur le projet, deux outils de développement agentiques sont utilisés : Cursor et Claude Code. À date, le projet compte plus de 35 skills, agents et règles in-house spécifiques au projet pour améliorer le harness des agents : faire respecter les conventions, guider les agents, améliorer leur productivité et automatiser certaines vérifications. C’est d’ailleurs un concept clé : la valeur générée par les IA ne vient pas seulement du modèle, mais du cadre dans lequel on le fait travailler.

Là où l’IA est un véritable accélérateur

Les meilleurs cas d’usage sont ceux où la tâche est assez structurée pour être guidée et assez longue pour permettre un gain significatif.

Sur ce projet, deux exemples ont été particulièrement parlants.

D’abord, la génération de contrats de données et d’exports associés à destination de l’équipe data. Ce type de travail demande de la rigueur, beaucoup de cohérence de nommage, une bonne compréhension des structures et des formats attendus. L’IA aide à produire plus vite une première version, mais aussi à repérer les incohérences.

Le projet étant un replatforming, la génération de scripts de migration depuis une plateforme legacy vers la nouvelle plateforme a aussi été un bon cas d’usage. Là encore, on ne confie pas aveuglément la migration à un agent. Mais pour produire des scripts, documenter les mappings, préparer des transformations et vérifier des cas répétitifs, l’aide est réelle.

Les gains existent, mais ils ne sont pas magiques

Sur un projet court, avec une petite équipe et une base de code limitée, les gains liés à l’IA peuvent être très visibles. On entend souvent parler de 30 % à 40 % d’efficacité, un ordre de grandeur que l’on partage volontiers chez Dernier Cri, surtout pour les tâches répétitives, bien cadrées et peu dépendantes d’un contexte métier complexe. La caractéristique des petits projets est aussi le nombre d’intervenants plus faible, avec des rôles plus larges. Comme nous l’avons vu précédemment, l’IA ne remplace pas l’humain, mais elle l’augmente dans la limite de ses prérogatives.

Ainsi, sur un projet de cette taille, les gains sont plus diffus, le scope de chacun étant plus limité. Il y a des cycles de validation métier, des enjeux de migration, des arbitrages réguliers et nécessaires, des contraintes de sécurité et une coordination quotidienne. Dans ce contexte, un ordre de grandeur de 10 à 20 % sur l’amélioration de la productivité est plus réaliste. Sur 8 mois de projet, c’est considérable. Mais ce n’est pas une division par deux du coût projet. L’IA permet d’aller plus vite sur certaines tâches, de mieux industrialiser, de renforcer les contrôles et de capitaliser davantage. Pour autant, elle ne supprime pas les temps incompressibles : cadrage, arbitrages, validation métier, synchronisation, QA, déploiement, décisions d’architecture.

La question n’est donc pas : “Combien de personnes peut-on remplacer ?” mais plutôt : “Quelles parties du delivery peut-on rendre plus rapides, plus fiables et moins dépendantes de l’énergie individuelle ?”

La sécurité reste une limite très concrète

Il faut aussi parler de ce qui limite les usages. Dans notre cas, les politiques internes font que l’hébergement Azure et Azure DevOps sont assez verrouillés. Les contraintes de sécurité sont fortes, ce qui est normal sur un projet métier avec des données sensibles, des accès contrôlés et une gouvernance client.

Atlassian est bien configuré et utilisé, avec Jira pour le suivi et Confluence pour la documentation. Mais les MCP restent fermés. Les agents ne peuvent donc pas interroger librement ces sources comme ils le feraient dans un environnement plus ouvert.

C’est le revers de la médaille. À date, ces contraintes nous empêchent d’aller plus loin sur certains scénarios :

• laisser des agents préparer ou déclencher certains déploiements ;
• leur donner accès à des données réelles ;
• les brancher aux logs applicatifs pour produire un premier diagnostic d’anomalie ;
• les connecter directement à des systèmes internes.

On peut regretter de ne pas exploiter tout le potentiel technique des agents. Mais en pratique, un bon déploiement de l’IA doit respecter le niveau de risque acceptable du projet. Le but n’est pas d’avoir l’agent le plus libre possible. Le but est d’avoir un agent utile dans un cadre maîtrisé.

Au quotidien, ces contraintes sont parfois frustrantes. Elles restent pourtant essentielles dans un produit professionnel durable.

Le dernier kilomètre reste humain

Il y a enfin un point qu’il faut répéter : l’IA ne garantit pas un résultat final directement au bon niveau. Sur un produit où la qualité de l’expérience utilisateur est importante, le dernier kilomètre reste déterminant : finition UI, cohérence des parcours, accessibilité, qualité perçue, validation métier, ajustements fins.

Un agent peut produire un composant. Il peut aider à écrire un test. Il peut suggérer une correction. Il peut expliquer une fonction. Mais il ne sait pas toujours sentir qu’un écran est presque juste, mais pas encore assez bon. Il ne porte pas la responsabilité du produit livré.

C’est là que l’exigence de l’équipe reste centrale. L’IA accélère la production, mais elle peut aussi accélérer la production de médiocrité si personne ne tient la barre.

Ce qu’on peut en retenir

Le retour d’expérience est assez clair : l’IA est une composante de la colonne vertébrale de notre delivery. Elle aide à produire, vérifier, documenter, tester, migrer, synthétiser et transmettre.

L'impact de l'IA dépend fortement de l’organisation et du terrain dans lequel elle évolue. Sur ce projet, l’IA ne emplace ni le product, ni le design, ni la technique, ni la QA, ni les arbitrages . Elle réduit le coût de nombreuses opérations, améliore la régularité de certains contrôles et aide l’équipe à capitaliser.