Deux questions pour l’ingénierie d’entreprise : la manière dont nous concevons les logiciels doit-elle changer, et en quoi devrait-elle se transformer ?
Depuis 50 ans, une profession est là, bien en vue : le programmeur. Ce que cette profession produit est discrètement devenu ce sur quoi tout le reste fonctionne.
L’ampleur du changement est facile à sous-estimer. En 1980, les États-Unis comptaient environ 300 000 emplois dans la programmation informatique, selon les données du Bureau of Labor Statistics rapportées par Fortune, 2025, et les machines pour lesquelles ces personnes écrivaient du code se trouvaient dans des salles que le grand public ne pénétrait presque jamais. Une voiture de cette époque embarquait une puce à fonction unique pour synchroniser ses bougies d’allumage.
Aujourd’hui, environ 6 milliards de personnes, soit près de 74 % de l’humanité, sont en ligne, selon l’UIT, 2025. Les dépenses informatiques mondiales devraient atteindre 6 370 milliards de dollars cette année, dont plus de 1 470 milliards de dollars consacrés aux logiciels, selon Gartner, 2026. Dans le monde, environ 36,5 millions de personnes codent professionnellement, tandis qu’environ 10 millions d’autres le font comme passe-temps, dans le cadre de leurs études ou comme compétence secondaire, selon SlashData, 2025. Et cette voiture est désormais livrée avec environ 100 millions de lignes de code réparties sur plus d’une centaine de contrôleurs, une estimation de 2021 qui est presque certainement plus élevée aujourd’hui.
À un moment donné, le logiciel a cessé d’être une catégorie de produits pour devenir le moyen par lequel les gens accèdent à leur argent, à leurs soins médicaux et à leur gouvernement. Personne ne peut y échapper. Et avec l’IA, elle-même un logiciel et un moteur permettant d’en produire davantage, la courbe s’accentue au lieu de s’aplatir.
Ce qui soulève deux questions. La première est évidente. La seconde mérite votre attention.
La manière dont nous produisons les logiciels doit-elle changer ?
Oui. Pas parce que les outils sont devenus meilleurs, mais parce que les enjeux ont changé, et parce que l’ajout d’un outil rapide à un processus lent crée de nouveaux problèmes.
Une femme a déposé sa déclaration fiscale via un nouveau portail gouvernemental au printemps dernier. Il a planté deux fois. Le message d’erreur accusait « un trafic élevé ». Ce n’était pas le trafic. L’agence avait livré du code plus rapidement que quiconque ne pouvait le tester ou le vérifier. Elle a envoyé à nouveau sa déclaration par courrier. Personne n’a qualifié cela d’échec. Les pull requests comptaient toujours comme des progrès.
Cet échec est structurel, pas accidentel. Les exigences sont rédigées pour être lues lentement par des humains. Les étapes de revue sont dimensionnées pour le volume produit par une équipe humaine au cours d’un sprint. Les plans de test supposent qu’une personne a écrit le code et qu’une autre le lira attentivement avant sa mise en production. Ajoutez un assistant de codage IA à ce pipeline et vous n’avez pas supprimé la contrainte, vous l’avez déplacée. Le code arrive désormais plus vite que la revue, les tests, la validation de sécurité et l’approbation du déploiement ne peuvent l’absorber. Le citoyen ne voit aucune de ces étapes. Il voit le délai d’expiration.
Les chiffres disent la même chose. Selon Gartner, 2025, les entreprises qui appliquent l’IA uniquement à la génération de code obtiennent environ 10 % de gains de productivité au niveau du système, tandis que les équipes qui appliquent systématiquement l’IA à l’ensemble du cycle de vie, des exigences aux opérations, devraient atteindre 25 à 30 % d’ici 2028. L’adoption n’a jamais été le plus difficile : selon Gartner, 2025, 90 % des ingénieurs d’entreprise devraient utiliser des assistants de codage IA d’ici 2028, contre moins de 14 % en 2024.
La productivité des développeurs et l’expérience du citoyen ne mesurent pas la même chose. L’une compte la production par personne. L’autre compte si une personne réelle a obtenu ce pour quoi elle était venue. Une équipe peut améliorer le premier indicateur pendant un an et constater que les plaintes évoluent à peine.
En quoi devrait-elle se transformer ?
Pas en un autre assistant de codage. Le travail consiste à gouverner ce que les agents sont autorisés à faire une fois qu’ils se trouvent déjà dans le pipeline. Quatre étapes, dans cet ordre.
- Définir la limite avant que l’agent ne touche au dépôt. Ce qu’il est autorisé à modifier, qui examine ce qu’il produit et comment cette décision est enregistrée. La plupart des entreprises n’ont pris aucune de ces décisions. Elles ont activé les outils et espéré que le processus finirait par suivre.
- Classer les revues selon le risque, et non selon l’habitude. Les changements routiniers à faible enjeu bénéficient d’une validation automatisée. Tout ce qui touche aux données d’une personne, à un paiement ou à une frontière de conformité conserve une validation humaine avec une justification enregistrée. Cela ne signifie ni tout vérifier manuellement, ni ne rien vérifier, mais bien repenser le processus.
- Conserver une traçabilité capable de répondre à la question difficile six mois plus tard. Ce que l’agent a modifié, pourquoi et sous quelle autorité. L’explicabilité cesse d’être un sujet de recherche lorsqu’un régulateur, un auditeur ou un client pose la question.
- Mesurer la personne à l’autre bout. Identifier où le travail généré par l’IA reste réellement bloqué, et non l’endroit où il s’exécute le plus rapidement. L’indicateur qui compte est de savoir si elle a pu déposer sa déclaration fiscale.
« Exige des responsables de l’ingénierie logicielle qu’ils repensent leurs stratégies », c’est ainsi que Joachim Herschmann, VP Analyst chez Gartner, a décrit ce que le développement basé sur les LLM exige désormais des organisations d’ingénierie.
C’est précisément à ce niveau que s’articule la pratique de Calsoft dédiée à l’ingénierie de systèmes intelligents à grande échelle : un développement d’IA agentique avec une autonomie contrôlée, et non des agents opérant sur des systèmes de production sans limites définies. La gouvernance n’est pas la partie que les entreprises ajoutent après coup lorsque le SDLC natif de l’IA fonctionne. C’est la partie qui protège la personne à l’autre bout de la transaction.
En 1980, la production d’un programmeur était un produit. Aujourd’hui, elle constitue une infrastructure dont 6 milliards de personnes ne peuvent se passer. Une suite de tests plus rapide ne sert à rien si le citoyen rencontre toujours un formulaire défaillant. Un pipeline plus rapide ne sert à rien si personne ne peut expliquer pourquoi sa déclaration a échoué deux fois.
Les entreprises qui réussiront ne seront pas celles qui auront généré le plus de code avec l’IA d’ici décembre. Ce seront celles dont les citoyens et les clients ne remarqueront plus les logiciels, simplement parce qu’ils fonctionneront.
FAQs
Pourquoi la production logicielle doit-elle être restructurée maintenant ?
Parce que la dépendance a changé. Le logiciel est passé d’une catégorie de produits au moyen par lequel des milliards de personnes accèdent à leur argent, aux soins de santé et aux services publics. L’IA génère désormais du code plus rapidement que la revue, les tests, la validation de sécurité et l’approbation du déploiement ne peuvent l’absorber, alors que tous ces processus sont encore dimensionnés pour les volumes d’avant l’IA. La contrainte s’est déplacée en aval ; le processus, lui, n’a pas changé.
Qu’est-ce qu’un SDLC natif de l’IA ?
Un cycle de vie du développement logiciel reconstruit autour d’agents IA travaillant à chaque étape, des exigences aux opérations, plutôt qu’un assistant ajouté à un processus antérieur à l’IA. Il remplace les workflows séquentiels au rythme humain par des revues basées sur le risque et une validation continue, afin que la personne qui utilise le logiciel rencontre moins d’échecs au lieu de recevoir simplement du code plus rapidement.
Comment les entreprises devraient-elles restructurer le SDLC pour l’IA ?
Définir les limites des agents avant qu’ils ne touchent au dépôt. Classer les revues selon le risque : validation automatisée pour les changements routiniers, validation humaine avec piste d’audit pour tout ce qui touche aux données, aux paiements ou à la conformité. Maintenir une traçabilité qui résiste à l’épreuve des mois et mesurer les résultats pour les clients plutôt que la production des développeurs.
