Calipia : le blog

Il existe deux façons de parler de l’impact de l’IA sur le développement logiciel : la méthode du conférencier enthousiaste qui projette des slides, et la méthode de celui qui a effectivement bousculé son organisation, mesuré les résultats, et s’interroge maintenant sur ce que cela signifie pour la profession. L’article publié sur VentureBeat appartient clairement à la seconde catégorie, et c’est précisément ce qui mérite qu’on s’y arrête sérieusement.

L’auteur, dirigeant d’une équipe d’ingénierie, livre un témoignage chiffré. Son équipe est passée de 36 à 30 ingénieurs au cours de l’année, tout en atteignant environ 170 % de travail de l’année précédente, soit un ratio d’environ deux fois plus de résultats produits avec 80 % des effectifs. Ce n’est pas une extrapolation ni une projection de cabinet de conseil : c’est une mesure observée sur six mois de transformation réelle. Pour un DSI, ce genre de chiffres mérite d’être placé dans son contexte avant d’être repris en comité de direction…

La fin du coût de l’expérimentation

L’un des arguments les plus convaincants de ce retour d’expérience porte sur la structure économique du processus de développement. Avant l’IA, tester une hypothèse produit supposait un investissement conséquent : on peaufinait les parcours utilisateurs pendant des semaines avant d’écrire la première ligne de code, même dans les organisations se réclamant de l’Agile.

Une fois passé en mode AI-first, ce compromis a disparu. Le coût de l’expérimentation s’est effondré : une idée peut aller du tableau blanc à un prototype fonctionnel en une journée, en passant successivement par un document d’exigences produit généré par l’IA, une spécification technique générée par l’IA, puis une implémentation assistée par l’IA.

Pour les architectes qui ont vécu les débats interminables sur la valeur du MVP et du « fail fast », voilà une réponse pragmatique. Le site web de cette organisation, décrit comme un système à l’échelle d’un produit avec des centaines de composants personnalisés, est maintenant conçu, développé et maintenu directement en code par… le directeur créatif. Oui, vous avez bien lu. On repassera pour la notion de séparation des rôles métier et technique.

La géométrie du projet retournée

Le modèle traditionnel d’organisation ressemblait à un diamant : une petite équipe produit passait la main à une grande équipe d’ingénierie, qui se réduisant à nouveau pour les tests finaux avant livraison et validation de la qualité logiciel. Aujourd’hui, cette géométrie s’inverse. Les humains s’impliquent davantage en amont, pour définir les intentions et explorer les options, et à nouveau en aval pour valider les résultats. La partie centrale, là où l’IA exécute, est plus rapide et plus étroite. 

Ce n’est pas un simple changement de workflow, c’est une inversion structurelle. Le modèle ressemble moins à une chaîne de montage et plus à une tour de contrôle : les humains fixent le cap et les contraintes, l’IA assure l’exécution, et les personnes reviennent en jeu pour valider avant que les décisions n’arrivent en production.

Pour un DSI, cette inversion a des implications directes sur les profils recherchés, les grilles de compétences et la façon d’évaluer la séniorité dans les équipes. Un développeur senior qui ne sait que coder sans penser à l’orchestration d’agents ou à la définition formelle de la correction devient structurellement moins stratégique qu’un ingénieur Qualité Logiciel qui, lui, a appris à formaliser ce que signifie « bon résultat ».

La qualité logiciel, nouveau pivot de la chaîne de valeur

C’est sans doute le renversement le plus surprenant. Dans une organisation traditionnelle, la majorité des personnes écrit du code et un groupe plus restreint le teste. Mais quand l’IA génère une grande partie de l’implémentation, le point de levier se déplace. La valeur réelle réside dans la définition de ce que signifie « correct », dans la capacité à rendre la correction explicite et formalisable. 

Les ingénieurs qualité ont évolué en architectes de systèmes. Ils construisent des agents IA qui génèrent et maintiennent des tests d’acceptation directement à partir des exigences, agents qui sont intégrés dans les workflows codifiés permettant d’obtenir des résultats d’ingénierie prévisibles. 

Le « shift left » prend ici un sens nouveau : la validation n’est plus une fonction autonome mais partie intégrante du processus de production. Si un agent ne peut pas valider son propre travail, il ne peut pas être fiable pour générer du code de production. Cette formulation devrait figurer dans tous les référentiels de gouvernance IA des DSI.

La meta-couche : orchestrer plutôt que coder

Très interessant ici de mon point de vue, l’auteur développe une analogie historique qui mérite réflexion. Chaque grand saut dans le logiciel a relevé le niveau d’abstraction : des cartes perforées aux langages de haut niveau, du matériel vers le cloud. L’IA constitue l’étape suivante : les ingénieurs travaillent désormais à une meta-couche, orchestrant des workflows d’IA, réglant des instructions et des compétences d’agents, et définissant des guardrails. Les machines construisent ; les humains décident quoi et pourquoi. 

Les équipes décident désormais régulièrement quand la production d’un agent IA peut être fusionnée sans revue humaine, à quel point borner l’autonomie d’un agent dans les systèmes de production, et quels signaux indiquent réellement la correction à l’échelle, des décisions qui n’existaient tout simplement pas auparavant. 

Pour les architectes d’entreprise, ce passage vers une meta-couche n’est pas anodin. Il repose sur la capacité à codifier des guardrails efficaces, à instrumenter des métriques de confiance envers les agents, et à définir des seuils de revue humaine. Ce travail est fondamentalement différent du développement de fonctionnalités, et les organisations qui le maîtriseront en premier prendront un avantage structurel difficile à combler.

Ce que l’article ne dit pas, mais qu’un DSI doit entendre

Si le retour d’expérience est honnête dans ses mesures, il présente quelques angles morts qu’il convient de souligner. L’organisation décrite semble de taille modeste (36 ingénieurs au maximum) et développe un produit clairement délimité. Les effets d’une telle transformation dans une DSI de 300 personnes, avec des systèmes legacy, des contraintes réglementaires et des équipes de sous-traitants, constituent un problème d’une toute autre nature…

Par ailleurs, la réduction d’effectifs de 36 à 30 personnes présentée comme neutre mérite une interrogation : s’agit-il de départs naturels, de non-remplacements, ou d’une réduction délibérée ? La formulation reste volontairement floue sur ce point. Pour tout DSI qui envisage une transformation similaire, la question des impacts sur les équipes et de l’accompagnement au changement reste entière.

Enfin, la dépendance croissante à des agents qui génèrent du code de production pose des questions de traçabilité, de maintenance à long terme, et de gestion des incidents qui ne sont qu’effleurées dans l’article. Quand un bug critique survient en production à 3h du matin et que son auteur est un agent IA, la chaîne de responsabilité doit avoir été pensée en amont.

Ce que cela signifie concrètement

Pour ceux qui observent cette transformation, trois actions méritent d’être engagées sans tarder. D’abord, investir dans la formalisation de la correction : définir explicitement ce que « bon » signifie dans chaque domaine métier est désormais un actif stratégique, pas seulement une bonne pratique. Ensuite, reconsidérer les parcours de carrière et les grilles de compétences : les profils hybrides capables de raisonner sur la validation, l’orchestration et les guardrails deviennent centraux. Enfin, instrumenter avant de déléguer : on ne donne pas d’autonomie à un agent sans avoir défini les métriques qui permettent de mesurer si cette autonomie est bien exercée.

Le paradoxe de l’ingénierie AI-first, c’est qu’elle ressemble moins à du codage et davantage à de la pensée. Pour une profession qui s’est longtemps définie par sa capacité à produire du code, c’est un changement d’identité aussi bien que de méthode.

Nous reviendrons sur ceci au travers de deux sessions du prochain Briefing Calipia en juin :d’une part sur une sessions dédiée au Vibe Coding et ses conséquences que j’aurais le plaisir d’animer avec des démonstrations, mais aussi sur l’impact de l’IA sur l’emploi qui sera animée par Patrick.