Habr : les agents IA bouleversent le delivery et obligent les équipes à repenser tout le cycle de développement

Habr publie une analyse expliquant pourquoi, avec l'arrivée des agents IA, les équipes d'ingénierie ne butent plus sur la vitesse d'écriture du code, mais sur le coût de la vérification et de la transmission du contexte. L'auteur cite le rapport DORA 2025 : 90% des professionnels de la tech utilisent l'IA au travail, et plus de 80% l'associent à un gain de productivité. Mais plus le code, les ADR et la documentation sont produits vite, plus la charge pesant sur la revue et le contrôle de la stabilité augmente.

L'auteur propose donc de ne pas voir l'IA comme un outil de plus greffé sur l'ancien processus, mais comme l'occasion de reconstruire tout le cycle de livraison des changements. L'article distingue trois modes de travail. Le premier, l'ai-assisted development : le modèle aide à recueillir plus vite les exigences, à rédiger des brouillons d'ADR, des cas de test ou de la documentation, mais le processus reste inchangé.

Le second, l'agentic delivery : l'agent lit désormais le dépôt, prépare les modifications, lance les vérifications et ouvre la PR, tandis que l'humain intervient sur les escalades. Pour illustrer ce basculement, l'auteur mentionne le passage de GitHub Copilot coding agent en general availability. Le troisième mode, l'ai-native sdlc : le LLM cesse d'être un « chat sur le côté » et devient l'interface d'un circuit de travail par lequel l'équipe fait avancer une tâche de l'idée jusqu'à la release.

La thèse centrale du texte : l'économie de cette transition ne repose pas sur le code, mais sur la communication. Dans un delivery réel, ce qui coûte cher, ce ne sont pas seulement les modifications elles-mêmes, mais aussi le passage de relais entre analyse, développement, test et exploitation, la reconstitution répétée des connaissances et les clarifications permanentes. Quand la génération s'accélère, le goulot d'étranglement se déplace vers les validations croisées, la vérification et la maîtrise des risques.

Les équipes ont donc besoin d'un contexte externe, lisible par la machine et accessible aussi bien aux humains qu'aux agents : objectifs, contraintes, risques, critères de done, ADR, contrats d'API, règles de sécurité, commandes de vérification locale et notes de rollout. Si les connaissances critiques continuent de vivre dans les chats, les visios et la mémoire de quelques développeurs, l'agent travaille simplement à partir d'une image incomplète. D'où un nouvel accent sur le harness, l'environnement d'exécution des agents.

Il ne s'agit plus d'un gros prompt système, mais d'un ensemble de règles et de contraintes intégrées au processus. Le dépôt doit contenir des instructions explicites pour les agents, les commandes de build et de test, les critères de done, ainsi que les contraintes d'architecture et de sécurité. Les scénarios récurrents doivent être formalisés en skills, playbooks et repo rules, plutôt que réexpliqués dans chaque chat.

Et ces contraintes ne doivent pas être uniquement textuelles : le système doit pouvoir bloquer les actions risquées, interdire un merge sans validation et renvoyer les étapes litigieuses vers un humain. L'auteur consacre une partie à la couche de contrôle. La revue ne doit pas recevoir un simple diff, mais un evidence pack : ce qui a précisément changé, quels scénarios sont couverts, quelles vérifications ont été exécutées, quels risques subsistent et comment annuler le changement.

Par-dessus, il faut des quality gates : limites sur la taille des modifications, commandes validate obligatoires, vérification des contraintes d'architecture et mise à jour synchrone de la documentation. Autre couche : les evals pour les tâches récurrentes. Elles permettent de fixer explicitement le comportement attendu de l'agent et de vérifier que le workflow reste stable après chaque nouvelle modification, plutôt que de laisser le processus glisser vers une version coûteuse du vibe coding, avec un flot de PR bruyantes.

Après la release, selon l'auteur, il faut surveiller non seulement le produit, mais aussi le processus de livraison lui-même. L'équipe doit analyser où l'agent a manqué de contexte, quelles règles se sont révélées trop faibles, quelles tâches étaient trop grosses pour être déléguées en toute sécurité et où la revue s'est noyée dans le bruit. Cela a un impact direct sur l'organisation : la valeur des ingénieurs polyvalents augmente, le rôle du platform engineering et de l'outillage interne se renforce, et l'onboarding des juniors cesse d'être un effet secondaire naturel du travail.

Faute de quoi, l'équipe risque de former non pas des ingénieurs, mais des opérateurs d'autocomplétion. La conclusion pratique de l'article de Habr : les agents IA ne rendent pas à eux seuls le delivery mature. Ils ne font qu'amplifier les forces et les faiblesses du système d'ingénierie existant.

La prochaine étape pour les équipes ne consiste donc pas simplement à générer plus vite du code et des documents, mais à bâtir un processus où le contexte est externalisé, l'environnement d'exécution encadré, les vérifications formalisées, et où chaque incident améliore non seulement le produit, mais aussi la manière de le livrer.