Workflows de développement IA : comment les équipes d’ingénierie livrent réellement du

En avril dernier, le PDG de Shopify, Tobi Lutke, a publié une note interne à l’ensemble de l’entreprise qui a fait trembler l’industrie technologique. Le message était sans détour : l’utilisation de l’IA n’est plus optionnelle. Chaque équipe demandant des effectifs supplémentaires doit d’abord démontrer que l’IA ne peut pas accomplir la tâche. Les évaluations de performance intègreraient désormais la maîtrise de l’IA. Lutke a lui-même partagé la note publiquement, prenant les devants sur l’inévitable fuite.

Ce qui rendait le mandat de Lutke remarquable n’était pas son ambition mais son timing. Au moment où cette note circulait, le changement qu’il exigeait s’était déjà produit dans des dizaines d’organisations d’ingénierie. La question n’était plus de savoir s’il fallait utiliser l’IA dans le développement logiciel. C’était comment l’utiliser sans perdre ce qui rend le logiciel fiable : la discipline de revue de code, la cohérence architecturale et le savoir institutionnel qui réside dans la mémoire musculaire collective d’une équipe.

Le nouveau cycle de développement

La boucle traditionnelle de développement logiciel — écrire du code, soumettre une pull request, attendre la revue, itérer — a été fondamentalement restructurée dans les entreprises qui livrent du logiciel de production avec l’IA. Ce qui a émergé est ce que les ingénieurs appellent la boucle « spécification-brouillon-revue-test », et cela ne ressemble en rien au modèle d’autocomplétion dopée aux stéroïdes qui définissait la première vague d’outils de codage IA.

Voici comment cela fonctionne en pratique. Un chef de produit ou un responsable technique rédige une spécification, souvent une description en langage naturel de ce qui doit être fait. Un agent IA prend cette spécification et produit un premier brouillon — pas un extrait de code, mais une implémentation complète couvrant plusieurs fichiers, avec des tests, des ébauches de documentation et une gestion des erreurs. Un ingénieur humain examine le brouillon, non pas ligne par ligne au sens traditionnel, mais architecturalement : cette approche s’intègre-t-elle au système ? Respecte-t-elle nos conventions ? Introduit-elle une dette technique que nous regretterons ?

Ensuite, l’IA exécute la suite de tests. Si des tests échouent, elle corrige le code et les relance. La boucle continue jusqu’à ce que l’implémentation passe, moment auquel un humain donne son approbation finale.

Chez Stripe, ce cycle a atteint une échelle quasi industrielle. Les agents IA maison de l’entreprise, appelés en interne « Minions », fusionnent désormais plus d’un millier de pull requests chaque semaine — un chiffre qui a récemment dépassé les 1 300 selon les propres communications de Stripe. Ce ne sont pas des modifications de formatage triviales. Les PR ne contiennent aucun code écrit par un humain — les ingénieurs définissent la tâche via une commande Slack, le CLI ou un bouton « Fix with Minion » dans le traqueur de bugs, et l’agent gère tout, de l’implémentation aux vérifications CI.

La nuance critique : les humains examinent toujours chaque pull request. Le code est écrit par l’IA mais approuvé par l’humain. Stripe a construit une infrastructure à six couches autour de son agent — un fork de l’outil’open source Goose de Block — avec un serveur MCP central appelé Toolshed hébergeant plus de 400 outils et intégrations internes. Les environnements des agents n’ont pas d’accès internet ni d’accès à la production. L’isolation est le système de permissions.

L’ingénierie augmentée de Shopify

Shopify aborde l’intégration de l’IA différemment de Stripe, mais le résultat est similaire. L’entreprise formule sa stratégie comme de l' »Augmented Engineering » — rendre les ingénieurs considérablement plus productifs en intégrant l’IA dans leurs workflows quotidiens plutôt qu’en remplaçant entièrement ces workflows.

Tous les employés de Shopify ont désormais accès à une suite d’outils IA incluant GitHub Copilot, Claude d’Anthropic et Cursor. L’entreprise ne fixe aucune limite aux dépenses en tokens IA. Les designers produit sont censés produire des prototypes de fonctionnalités à l’aide d’outils IA. L’équipe plateforme d’ingénierie a construit un Dev MCP Server qui permet aux agents IA de créer des applications Shopify complètes, d’exécuter des opérations GraphQL et de générer du code validé à travers l’Admin, les extensions UI, les templates Liquid et le framework de vitrine Hydrogen.

La philosophie derrière l’Augmented Engineering est pragmatique plutôt qu’utopique. À mesure que la complexité de l’ingénierie augmentait — plus d’intégrations, plus de surface de plateforme, plus d’options de personnalisation pour les marchands — Shopify a constaté que l’IA pouvait absorber la charge cognitive. Plutôt que d’embaucher proportionnellement plus d’ingénieurs, ils ont utilisé l’IA pour maintenir la vélocité de production constante même à mesure que le système devenait plus complexe. Fait notable, Shopify continue de recruter — y compris un millier de stagiaires — signalant que la priorité à l’IA ne signifie pas réduction des effectifs.

Vercel et le paradigme v0

L’approche de Vercel représente un troisième modèle : l’IA comme point de départ du développement plutôt que comme assistant pendant celui-ci. L’outil v0 de l’entreprise a évolué d’un simple outil de prototypage vers ce que le PDG Guillermo Rauch décrit comme un environnement de développement de niveau production supportant des workflows Git complets — ce que l’industrie appelle désormais le « vibe coding ».

Ce qui distingue v0 d’un chatbot qui génère des composants React est l’infrastructure sous-jacente. Un runtime basé sur des sandboxes peut importer n’importe quel dépôt GitHub et extraire automatiquement les variables d’environnement et les configurations depuis Vercel. Chaque prompt génère du code qui s’exécute dans un environnement réel, pas dans un bac à sable. Un panneau Git permet aux développeurs de créer une branche pour chaque conversation, d’ouvrir des pull requests contre la branche principale et de déployer à la fusion.

Vercel a lancé AI SDK 6 avec une abstraction d’agent native et un système d’approbation d’outils qui permet aux développeurs de contrôler toute action nécessitant une revue humaine. Définissez un outil avec needsApproval: true, et l’agent se met en pause jusqu’à ce que quelqu’un confirme. C’est l’équivalent en ingénierie de la règle des deux personnes pour le lancement de missiles, appliquée aux migrations de base de données et aux déploiements d’API.

Ce que les données montrent réellement

Le rapport DORA 2025, l’évaluation annuelle de Google sur la performance de livraison logicielle, dresse un tableau nuancé de l’impact de l’IA sur les équipes d’ingénierie. Le chiffre phare : 90 pour cent des professionnels du développement logiciel utilisent désormais des outils IA au travail, en hausse de 14 points de pourcentage par rapport à l’année précédente. Le développeur médian passe environ deux heures par jour avec des outils IA — soit environ un quart de sa journée de travail.

Les gains de productivité individuels sont réels. L’analyse des données DORA montre que les développeurs accomplissent 21 pour cent de tâches en plus et fusionnent 98 pour cent de pull requests en plus lorsqu’ils utilisent des assistants IA. Mais voici le paradoxe qui empêche les responsables d’ingénierie de dormir : les métriques de livraison organisationnelles ne se sont pas améliorées proportionnellement. Alors que le rapport 2025 a constaté que l’adoption de l’IA corrèle désormais positivement avec le débit de livraison — un retournement par rapport au constat négatif de l’année précédente — elle continue de corréler négativement avec la stabilité de livraison. Plus de code est livré plus rapidement, mais l’instabilité augmente parallèlement. Le temps de revue de code augmente de 91 pour cent à mesure que le volume de PR submerge les relecteurs, la taille des pull requests gonfle de 154 pour cent, et le taux de bugs grimpe de 9 pour cent alors que les contrôles qualité peinent à suivre le rythme.

Les chercheurs DORA décrivent cela comme l’effet d’amplification. L’IA ne répare pas une équipe défaillante. Elle amplifie ce qui est déjà en place. Les équipes solides avec des architectures faiblement couplées, des boucles de rétroaction rapides et des tests automatisés robustes utilisent l’IA pour devenir plus rapides et plus fiables. Les équipes en difficulté — celles avec des systèmes fortement couplés, des pipelines CI lents et de mauvaises pratiques de revue — constatent que l’IA ne fait que magnifier leur dysfonctionnement.

Les équipes qui obtiennent de véritables gains de productivité partagent trois caractéristiques. Premièrement, elles disposent de suites de tests automatisés solides qui détectent les régressions avant que le code généré par l’IA n’atteigne la production. Deuxièmement, elles travaillent dans des architectures faiblement couplées où les modifications dans un service ne se propagent pas en cascade dans les autres. Troisièmement, elles ont investi dans des plateformes de développement internes qui fournissent un outillage standardisé, réduisant la surface où l’IA peut introduire de l’incohérence.

Mesurer ce qui compte

Les métriques DORA traditionnelles — fréquence de déploiement, délai de mise en oeuvre des changements, taux d’échec des changements et temps de restauration du service — restent importantes mais de plus en plus insuffisantes. Le rapport 2025 élargit le cadre pour inclure la performance d’équipe, la performance produit, le travail de valeur (construisons-nous les bonnes choses), les frictions (où les développeurs sont-ils bloqués), l’épuisement professionnel et l’efficacité individuelle.

Les équipes les plus sophistiquées ont cessé de mesurer les « lignes de code générées par l’IA » et ont commencé à mesurer le « temps entre l’idée et la fonctionnalité validée ». Cette métrique capture le cycle complet : spécification, implémentation, revue, test et déploiement. Il s’avère que l’IA compresse dramatiquement la phase d’implémentation mais ne fait pratiquement rien pour les phases de spécification et de revue, qui restent obstinément à vitesse humaine.

Certaines équipes rapportent que l’IA a déplacé le goulot d’étranglement en amont. Quand l’implémentation prend des heures au lieu de jours, la contrainte devient la vitesse à laquelle les chefs de produit peuvent rédiger des spécifications claires et la vitesse à laquelle les ingénieurs seniors peuvent examiner les décisions architecturales. La partie la plus lente du pipeline est désormais celle qui requiert le jugement humain sur ce qu’il faut construire et si cela a été correctement construit.

La réalité du contrôle humain

Malgré le discours marketing autour du codage IA « autonome » et « agentique », chaque équipe d’ingénierie de production maintenant des systèmes critiques applique une politique stricte de contrôle humain dans la boucle. La boucle s’est déplacée, cependant. Les ingénieurs n’écrivent plus du code pour que l’IA le vérifie. L’IA écrit du code et les humains le vérifient. L’ensemble de compétences requises est passé de la production de code à l’évaluation de code.

Cette distinction est fondamentale. Un ingénieur qui examine du code généré par l’IA a besoin d’un type d’expertise différent de celui qui l’écrit de zéro. Il doit comprendre l’architecture du système suffisamment en profondeur pour repérer quand une IA a produit une solution techniquement correcte mais architecturalement inappropriée. Il doit reconnaître quand une suite de tests passe mais ne teste pas réellement les choses qui comptent. Il doit détecter les bugs subtils qui surviennent quand une IA assemble des patterns issus de ses données d’entraînement qui ne correspondent pas tout à fait au contexte spécifique de cette base de code.

Plusieurs responsables d’ingénierie ont noté que les ingénieurs juniors font face à un défi particulier dans ce nouveau workflow. Sans l’expérience d’écrire du code de zéro, comment développent-ils le jugement nécessaire pour le relire ? Stripe répond à cela en exigeant que les ingénieurs juniors construisent des bases solides en programmation traditionnelle avant de s’appuyer sur les agents IA. D’autres ont mis en place des « journées sans IA » où les équipes codent sans assistance pour maintenir leurs compétences fondamentales.

La suite

La convergence se fait vers ce que l’on pourrait appeler la « fabrication logicielle » — un processus où les ingénieurs humains fonctionnent davantage comme des concepteurs de produits et des inspecteurs qualité que comme des ouvriers sur une chaîne de montage. L’IA gère la fabrication. Les humains gèrent la conception, l’inspection et les décisions de jugement qui déterminent si quelque chose devrait être construit ou non.

Ce n’est pas un scénario futur lointain. C’est en train de se produire maintenant dans des entreprises qui traitent des millions de transactions quotidiennement. Les équipes qui réussissent avec ce modèle partagent un trait commun : elles ont investi dans les fondamentaux de l’ingénierie — tests, architecture, culture de revue — bien avant d’adopter l’IA. Les outils amplifient la discipline. Ils amplifient aussi son absence.

Questions Fréquemment Posées

Sources et lectures complémentaires

• Minions: Stripe’s One-Shot, End-to-End Coding Agents — Stripe Engineering Blog
• DORA State of AI-Assisted Software Development 2025 — Google Cloud
• How AI Is Changing Software Engineering at Shopify — The Pragmatic Engineer
• Shopify CEO: AI Is Now a Fundamental Expectation for Employees — CNBC
• AI SDK 6 — Vercel Blog
• DORA Report 2025 Points Clés: AI Impact on Dev Metrics — Faros AI