Lorsque j'ai lu Rewiring software delivery for the agentic era de McKinsey, je n'y ai pas vu une vision lointaine de l'avenir. J'y ai reconnu notre propre manière de construire la plateforme 3R.
McKinsey commence par décrire une product owner qui examine le matin ce que des agents IA ont exécuté pendant la nuit. Les exigences ont été affinées, les choix d'architecture contrôlés, le code écrit et testé, et les décisions encore ouvertes sont prêtes pour une évaluation humaine. Personne n'a travaillé tard. Les agents se sont chargés de l'exécution.
L'article évoque une productivité multipliée par trois à cinq et une réduction d'environ soixante pour cent de la taille moyenne des équipes dans les premières applications. Nous ne disposons pas d'une mesure de référence contrôlée qui nous permettrait de revendiquer de tels chiffres pour 3R. Nous reconnaissons néanmoins pleinement le mécanisme sous-jacent. Notre vitesse de développement ne vient pas d'un seul assistant de codage plus performant. Elle vient d'un modèle de développement conçu autour de la collaboration entre les personnes et les agents.
Pour nous, le développement logiciel agentique n'est pas une expérience menée à côté de la construction de la plateforme. C'est notre manière de construire la plateforme.
Un ticket devient un lot de travail exécutable
Notre cycle de développement ne commence pas par un prompt approximatif demandant de construire une fonctionnalité. Une demande devient d'abord un ticket GitHub clairement délimité, avec le résultat attendu, les critères d'acceptation, l'impact prévu et les preuves qui permettront ensuite d'établir si le problème a réellement été résolu.
La différence peut sembler minime, mais elle détermine presque tout ce qui suit. Un agent ne peut travailler de manière autonome que si les données d'entrée sont suffisamment claires et structurées. Une idée vague produit du code plus rapidement, mais pas nécessairement le bon code. Un bon lot de travail donne à l'agent un problème à résoudre, des limites à respecter et un point d'arrivée vérifiable.
Une couche d'orchestration prend ensuite le relais. Selon la tâche, celle-ci est confiée à Codex Cloud, à un développeur numérique temporaire dans AWS ou à un agent sur une machine locale. Plusieurs tâches peuvent s'exécuter simultanément dans des fils de travail distincts. Les agents lisent les mêmes instructions du dépôt, repèrent le code pertinent et travaillent chacun sur leur propre branche. Ils effectuent les contrôles appropriés, enregistrent leurs modifications et ouvrent une pull request en brouillon.
Pour nous, c'est l'équivalent concret de l'agentic factory décrite par McKinsey. Une personne ne doit plus écrire elle-même chaque ligne de code ni coordonner manuellement chaque transfert technique. Le système transforme une question produit claire en une première solution contrôlable.
La chaîne ne s'arrête pas lorsque le code est écrit
Un agent de codage qui ouvre une pull request ne constitue pas encore un modèle de développement agentique. Sans le reste de la chaîne, on ne fait que produire plus rapidement de l'incertitude.
Chez 3R, l'implémentation n'est donc qu'une étape. L'agent effectue d'abord des contrôles techniques rapides. GitHub Actions prend ensuite en charge les vérifications plus lourdes. Selon la modification, la solution passe par des tests ciblés ou complets, y compris des tests dans le navigateur pour les différents rôles de la plateforme ainsi que des contrôles de sécurité de la base de données et d'étanchéité entre les clients.
Pour les modifications visibles, nous produisons également un enregistrement d'écran au ralenti. Nous pouvons ainsi examiner un nouveau parcours utilisateur pendant que les autres tests sont encore en cours. Il n'est pas nécessaire d'attendre la fin du cycle technique pour juger si la solution est compréhensible dans la pratique.
Parallèlement, un agent indépendant examine le code. Il vérifie non seulement si la modification semble techniquement valable, mais aussi si elle introduit des effets secondaires, des risques de sécurité ou des scénarios insuffisamment couverts. Ses constats retournent au même agent de développement. Ce n'est qu'après les corrections que l'ensemble des tests pertinents est réexécuté sur la version définitive.
C'est une différence importante par rapport à la programmation classique assistée par IA. Nous n'utilisons pas un agent qui écrit du code et approuve ensuite son propre résultat. L'implémentation, les tests, le contrôle indépendant et l'évaluation humaine constituent des responsabilités distinctes au sein d'une même chaîne continue.
L'humain ne disparaît pas, son travail se déplace
McKinsey décrit comment les rôles humains passent de la production d'artefacts à la conception et à l'amélioration du système qui les produit. C'est exactement ce que nous constatons pendant la construction de 3R.
La contrainte réside de moins en moins dans la capacité à écrire un composant, une fonction de base de données ou un test. Les véritables questions se situent avant et après ce travail. Nous devons déterminer précisément quel problème nous résolvons, si la solution correspond à la direction du produit, quelles exceptions comptent et quels risques restent acceptables. Une solution techniquement correcte doit aussi être réellement assez bonne pour intégrer le produit.
Ces décisions restent entre nos mains. Les agents peuvent analyser un ticket, produire du code, écrire des tests, proposer une première sélection de tests de régression et traiter les constats. Ils ne peuvent pas décider eux-mêmes que leur travail est prêt à être fusionné. Chaque pull request reste en brouillon jusqu'à ce que Johan ou Vincent ait explicitement approuvé la version actuelle. Si un agent apporte ensuite une modification, cette approbation devient caduque et le dernier contrôle recommence.
Ce n'est pas un frein à l'autonomie. C'est ce qui la rend exploitable. Les agents disposent d'une grande liberté dans les limites du lot de travail, tandis que la direction du produit, les choix d'architecture à fort impact et l'acceptation finale restent des responsabilités humaines.
La vitesse exige davantage de discipline, pas moins
Dans le développement assisté par IA, la tentation consiste à regarder surtout la quantité de code produite. C'est la mesure la moins intéressante. Les agents peuvent aussi construire une mauvaise solution à une vitesse remarquable.
Plus la vitesse d'exécution augmente, plus la qualité du système qui l'entoure devient importante. C'est pourquoi notre dépôt ne contient pas uniquement le code de l'application. Il contient aussi des instructions pour les agents de développement, des procédures propres à chaque tâche, des contrats de test, des règles de sécurité, des critères de décision et des procédures de récupération. Ces connaissances sont entretenues en même temps que le produit.
Lorsqu'un problème survient, nous ne nous contentons pas de corriger cette erreur précise. Nous examinons aussi pourquoi le système de développement l'a permise. La cause peut être un contexte manquant, un critère d'acceptation ambigu, une hypothèse risquée, un test absent ou un transfert imprécis entre l'implémentation et le contrôle. La correction doit alors se retrouver non seulement dans le code, mais aussi dans les instructions, les tests ou la procédure que le prochain agent utilisera.
Cette approche rejoint directement le plaidoyer de McKinsey en faveur d'une infrastructure de connaissances. Dans notre pratique, le dépôt n'est pas uniquement l'endroit où se trouve le code source. Il constitue aussi la mémoire partagée de l'équipe de développement, humaine et numérique. Les nouveaux agents ne doivent pas réapprendre depuis le début comment 3R est construit. Ils reçoivent les règles, les modèles et les enseignements actuels au moment de commencer une tâche.
Les transferts eux-mêmes sont devenus du logiciel
Le développement logiciel traditionnel comporte de nombreux transferts humains. Une personne rédige une analyse, un développeur l'interprète, un testeur reconstruit l'intention et une product owner tente ensuite de déterminer si le résultat est correct. Du sens peut se perdre à chaque transition.
Dans notre chaîne de développement agentique, ces transferts sont conçus explicitement. Le ticket contient le problème et les critères d'acceptation. L'agent de développement fournit le code, les résultats des tests et une pull request en brouillon. L'environnement de test relie ses preuves à la version précise du code. L'agent de contrôle indépendant formule des constats concrets. L'enregistrement d'écran montre ce que l'utilisateur verra réellement. À la fin, l'humain reçoit un dossier de décision contrôlable, plutôt qu'un ensemble d'artefacts techniques séparés.
Même l'orchestration est devenue un rôle distinct. Un agent suit la tâche associée à chaque ticket, la version du code qui a été testée, l'état du contrôle indépendant et la validité de l'approbation humaine. Il peut suivre le travail et renvoyer les corrections dans le même contexte, mais il n'écrit pas discrètement le code manquant et n'approuve rien en notre nom.
C'est peut-être le changement le plus important. Nous n'automatisons pas seulement le travail de programmation. Nous concevons également la collaboration, les preuves et les moments de décision comme des composants du système de développement.
Ce que nous apprenons encore
Notre approche n'est pas une usine achevée. Elle constitue elle-même un produit en cours de développement.
Nous apprenons à répartir les tâches sans perdre leur cohérence. Nous déterminons quels contrôles doivent être exécutés localement, dans le cloud ou dans GitHub Actions. Nous avons adapté l'infrastructure de test afin que plusieurs agents puissent travailler en parallèle en toute sécurité sans perturber leurs environnements respectifs. Nous affinons continuellement la frontière entre les décisions qu'un agent peut prendre seul et les choix d'architecture ou de données qui demandent d'abord un alignement humain.
Les coûts de l'autonomie deviennent également plus visibles. Déployer davantage d'agents ne produit pas automatiquement plus de progrès. Une mauvaise orchestration crée du travail en double, des modifications concurrentes et des cycles de test inutiles. Une implémentation rapide fondée sur une mauvaise hypothèse produit coûte toujours du temps. Le développement logiciel agentique ne supprime donc pas le besoin de discipline produit. Il sanctionne simplement son absence plus rapidement.
C'est précisément pour cette raison que l'article de McKinsey me paraît si familier. Les auteurs ne disent pas que les organisations doivent simplement déployer davantage d'agents. Ils affirment que l'ensemble de la structure de développement doit être repensé. Les exigences, les connaissances, l'architecture, les tests, le contrôle et les rôles humains doivent fonctionner comme un seul système.
Le véritable avantage réside dans le modèle de développement
La plateforme 3R est construite par une petite équipe centrale entourée d'une équipe de développement numérique en croissance. Nous pouvons ainsi travailler simultanément sur les fonctionnalités du produit, la protection des données, les tests, la documentation et les outils opérationnels, sans devoir d'abord constituer une structure d'équipe classique pour chaque spécialité.
La valeur ne réside pas uniquement dans la vitesse. Nous construisons une mémoire institutionnelle dans laquelle chaque correction peut améliorer le système. Nous pouvons montrer les modifications rapidement, les tester largement et les faire évaluer de manière ciblée. L'attention humaine peut alors se déplacer vers les domaines où elle apporte le plus de valeur : la direction du produit, la compréhension des utilisateurs, l'architecture et la responsabilité finale.
La manière dont nous construisons 3R est donc au moins aussi intéressante à mes yeux que les fonctionnalités de la plateforme. Nous conseillons aux organisations de repenser le travail autour des personnes et de leurs collègues numériques. En développant notre propre produit, nous découvrons chaque jour ce que cela exige réellement.
Le développement logiciel agentique n'est donc pas seulement une technologie que nous utilisons pour tenter de construire 3R plus rapidement. C'est un nouveau modèle opérationnel que nous sommes nous-mêmes en train de découvrir, de délimiter et d'améliorer. Le code en est le résultat visible. La véritable innovation réside dans le système qui produit ce code.