Les limites du SDLC piloté par l'IA : où l'on n'y va pas (encore)

Un chiffre résume mieux que tout l'état réel de l'IA en production. D'après une enquête Gartner relayée par l'éditeur Rippletide, 64 % des dirigeants techniques déclarent vouloir déployer de l'IA agentique dans les vingt-quatre mois — et 17 % seulement l'ont effectivement mise en production. Entre l'intention et le déploiement, il y a un fossé que les démonstrations de 2025 n'ont pas comblé. Et la même source ajoute une prévision qui glace : selon Gartner toujours, 40 % des projets d'IA agentique pourraient être annulés d'ici 2027, faute de maîtrise des coûts, de ROI clair et de contrôles de risque suffisants.

La tentation est de lire cet écart comme un problème de maturité technologique : il suffirait d'attendre le prochain modèle, plus puissant, pour le résorber. C'est un contresens. L'écart n'est pas un problème de modèle, c'est un problème de périmètre. Là où le résultat se prouve — là où l'on peut capturer une sortie, exécuter un test, vérifier un contrat —, un cycle de développement piloté par l'IA tient ses promesses. Là où le résultat ne se prouve pas, ne se certifie pas, ou repose sur des données non gouvernées, aucun modèle ne franchira la frontière à votre place.

La bonne question n'est donc pas « l'IA en est-elle capable ? » mais « où ma chaîne sait-elle prouver ce qu'elle produit ? ». Cet article dresse la carte : les cas où le SDLC augmenté excelle, et les trois frontières où l'on n'y va pas — ou pas encore. C'est, assumé, un discours d'honnêteté. Dans la série dont fait partie cet article, le pilier sur le SDLC augmenté pose le cycle complet — onze phases, trois gates humains, deux capitalisations — et rappelle une règle qui éclaire toute cette carte : un cycle augmenté amplifie autant les forces que les dysfonctions. Nommer ses limites, c'est refuser d'amplifier ce qu'on ne maîtrise pas.

Là où ça marche : ce qui s'explicite et ce qui se prouve

Commençons par le terrain solide, car il est plus vaste qu'on ne le croit. Le cycle augmenté excelle dans trois familles de situations, et toutes partagent une propriété : le résultat est vérifiable sans pari.

La première famille, c'est le contexte métier explicitable. Back-offices, APIs internes, portails, et surtout modernisation de legacy. Ce sont des domaines où l'on sait dire, noir sur blanc, ce que le système doit faire : la règle de gestion existe, le comportement attendu se décrit, le périmètre se borne. Prenons le cas — anonymisé — d'une enseigne leader de la grande distribution qui doit migrer un parc d'applications de back-office accumulé sur vingt ans. Le code source est là ; les comportements observables sont là ; les tests de non-régression peuvent être écrits et exécutés. Rien n'est à inventer : tout est à expliciter. C'est exactement le terrain où l'IA produit le plus de valeur, parce que chaque pas peut être prouvé contre l'existant.

La deuxième famille, c'est le volume répétitif et traçable : tests, migrations de masse, documentation, conformité. Le point commun, là encore, n'est pas la simplicité — une migration de quelques centaines d'endpoints n'a rien de simple — mais la traçabilité. Chaque unité de travail ressemble à la précédente, produit un artefact comparable, et laisse une trace exploitable. C'est le régime dans lequel les chiffres publics les plus spectaculaires apparaissent ; le pilier en cite, sous étiquette « Industrie », et notre article sur l'aval du cycle montre comment ce volume se déploie sans casse.

La troisième famille, la plus structurante, c'est ce qui se prouve automatiquement. C'est le critère qui unifie les deux autres. Tant qu'une sortie peut être capturée et confrontée à une attente — un test qui passe ou échoue, un type qui tient ou non, un contrat respecté ou violé —, la machine peut travailler en autonomie et l'humain vérifier la preuve plutôt que la déclaration. Le cadre tiers ADLC, construit indépendamment de SFEIR et que notre article sur la convergence des cadres détaille, dit la même chose dans son propre vocabulaire : les bons cas sont « ce qui se prouve déterministiquement — tests, types, contrats, builds » (Industrie · ADLC). Quand des équipes qui ne se parlent pas posent le même critère, ce n'est plus une opinion d'éditeur, c'est une propriété du problème.

Notez ce que ce critère exclut, et qui nous mène à la première frontière : tout ce dont le résultat ne se prouve pas tout seul.

L'inédit : l'IA explore, elle ne décide pas l'intention

La première frontière est la plus subtile, parce qu'elle ne se voit pas dans les démonstrations. C'est celle de l'inédit sans spec possible — le problème neuf, dont l'intention reste à inventer.

Il faut être précis sur ce qui est en jeu. Un agent est remarquable pour explorer un espace de solutions : générer dix variantes d'une architecture, prototyper trois approches d'un algorithme, défricher une bibliothèque inconnue. Cette capacité d'exploration est même un atout réel — et bon marché. Mais explorer n'est pas décider. Quand il n'existe pas encore de spécification, parce que personne n'a tranché ce qui mérite d'être construit, l'IA explore l'espace ; elle ne décide pas l'intention.

C'est le cœur de la doctrine que le pilier nomme : l'humain garde le contrôle aux gates parce que l'intention ne se délègue pas. Une machine optimise une fonction ; elle ne décide pas ce qui vaut la peine d'exister. Sur un problème inédit, la spec n'est pas un document à rédiger plus vite : c'est un acte de jugement qui n'a pas encore eu lieu. C'est précisément ce que travaille notre article sur l'amont du cycle, où une idée devient un contrat avant qu'une seule ligne ne soit écrite. Tant que ce contrat n'existe pas, accélérer la production reviendrait à courir plus vite dans une direction non choisie.

La nuance compte, car elle évite deux erreurs symétriques. La première serait de croire que l'IA peut tout inventer — le mythe de l'agent visionnaire. La seconde serait de lui interdire l'inédit — alors qu'elle y est précieuse, à condition de la cantonner à son rôle : explorer pour éclairer la décision humaine, pas se substituer à elle. La frontière n'est pas « pas d'IA sur l'inédit » ; elle est « l'IA propose, l'humain dispose, et c'est non négociable ».

Le certifiable : tant que la chaîne d'outils n'est pas qualifiée

La deuxième frontière est la plus dure, et la plus mal comprise. C'est celle du safety-critical certifiable : les domaines où un défaut logiciel peut tuer, et où une autorité exige une démonstration formelle de sûreté avant toute mise en service.

Dans l'avionique, c'est la norme DO-178C ; dans le ferroviaire, EN 50128 ; on retrouve des exigences voisines dans le médical ou le nucléaire. Le malentendu courant est de croire que la question est « l'IA écrit-elle du code assez bon pour ces domaines ? ». Elle est ailleurs. Ces normes ne certifient pas seulement le produit : elles exigent que la chaîne d'outils elle-même soit qualifiée. Un compilateur, un générateur de code, un outil de test, doivent faire l'objet d'une qualification d'outil — une démonstration que l'outil ne peut pas introduire d'erreur non détectée dans le processus. C'est une procédure lourde, formelle, et largement étrangère, pour l'instant, à la nature probabiliste des modèles de langage.

La conséquence est claire et il faut l'assumer sans détour : tant que la chaîne d'outils n'est pas qualifiée au sens de ces normes, l'IA ne se substitue pas à la vérification et à la validation — elle les renforce. C'est une distinction de rôle, pas de qualité. Un agent peut être un vérificateur supplémentaire redoutable : une revue parallèle de plus, capturant la sortie réelle d'exécution plutôt que la déclaration. Le pilier mentionne une revue menée sur « + de 4 » angles — code, sécurité, tests, performance ; sur un système certifiable, on ajoute des angles de contrôle, on ne retire pas de signatures humaines. La discipline de preuve — capturer 100 % des sorties, jamais le « claim » d'un agent — est ici un atout ; mais capturer une sortie n'est pas certifier un outil. Confondre les deux serait dangereux.

Cette frontière a une vertu : elle ne nie pas qu'un irréductible existe, y compris dans les cadres agentiques les plus avancés. L'ADLC tient, en toute franchise, ce qu'il appelle son honest loss account : l'élégance architecturale en une passe, l'intuition transverse, les refactors long-horizon qui résistent à la découpe représentent, selon le cadre, « ~5 % de travail sérialisé », sous supervision maximale (Industrie · ADLC). Cinq pour cent qui ne se parallélisent pas, ne s'automatisent pas, et restent profondément humains. Sur un système certifiable, ce noyau irréductible n'est pas une exception marginale : c'est le cœur de la responsabilité. La maturité consiste à le reconnaître, pas à prétendre qu'un meilleur modèle le fera disparaître.

Les données non gouvernées : la gouvernance d'abord

La troisième frontière est souvent celle qui bloque, en pratique, les projets qui semblaient pourtant relever des « bons cas ». Ce sont les données non gouvernées.

Le principe est simple à énoncer, exigeant à tenir : les données non gouvernées ne sont pas un terrain de jeu, elles sont un préalable. Avant d'agentiser un processus, il faut savoir où sont les données, qui y a droit, sous quelle juridiction elles résident, et quelle trace laisse chaque accès. Le cycle augmenté part d'ailleurs de là : sa toute première phase versionne le contexte — données, droits, souveraineté — comme prérequis, avant la moindre exécution. Tant que cette gouvernance n'est pas établie, lancer des agents sur le patrimoine de données n'accélère pas un problème : il l'amplifie.

Deux dimensions se superposent. La première est sécuritaire. L'article de Sonar dans AIJournal le documente sans ambages : les outils génératifs « produisent souvent des références et dépendances superflues » qui constituent une surface d'attaque — un acteur malveillant peut amener un agent à inclure une dépendance d'apparence anodine, plus tard armée. Et il cite une étude de Stanford peu rassurante : les développeurs équipés d'un assistant IA introduisent davantage de vulnérabilités, tout en jugeant leur code non sûr comme sûr. La donnée non gouvernée plus la confiance aveugle, c'est la combinaison qui transforme un gain de vitesse en passif.

La seconde dimension est souveraine. Lors de son audition devant la commission d'enquête de l'Assemblée nationale sur les vulnérabilités numériques, en mai 2026, Arthur Mensch, dirigeant de Mistral, posait que « le cloud, c'est l'intelligence artificielle » — il n'y a plus de frontière nette entre service numérique et IA — et avertissait, sur la fenêtre stratégique européenne : « si on ne le fait pas assez vite, on va devenir un État vassal. » Le propos dépasse la géopolitique : il rappelle qu'une donnée hébergée sous une juridiction étrangère obéit à des lois extraterritoriales. C'est précisément ce qu'adresse, côté français, la qualification SecNumCloud de l'ANSSI — « plus de 1 200 exigences » vérifiées, conçues notamment pour couvrir le risque du CLOUD Act et de FISA. Gouverner la donnée, ce n'est donc pas seulement chiffrer un bucket : c'est savoir, juridiquement, qui peut y accéder. Sans cette réponse, le projet n'est pas mûr — quelle que soit la qualité du modèle.

Pourquoi ces frontières existent : un modèle ne raisonne pas, il prédit

On peut maintenant remonter à la cause commune des trois frontières. Elle tient en une phrase, que Rippletide formule crûment : un grand modèle de langage est un prédicteur probabiliste de tokens, pas un raisonneur déterministe. Selon l'éditeur, ces systèmes « n'ont jamais été, et ne seront jamais, conçus pour raisonner » : ils excellent en reconnaissance de motifs, mais leur sortie reste statistique. De là découlent l'hallucination assurée, les décisions opaques, et une traçabilité difficile.

Ce constat n'est pas une condamnation — c'est une consigne d'architecture. Si le modèle ne garantit pas le déterminisme, alors la gouvernance ne doit pas vivre dans le modèle ; elle doit vivre autour de lui, dans une couche déterministe que l'on peut auditer. C'est l'inverse de l'illusion confortable où l'on demande à l'agent de se policer lui-même. La même logique innerve la revue à l'ère de l'IA, où l'on sépare le créateur du vérificateur, sujet de notre article dédié à la revue.

L'illustration la plus aboutie vient d'Uber, qui opère des milliers d'agents internes en production. Son équipe d'ingénierie part d'une définition limpide : « un agent est une entité autorisée à agir pour ou à la place d'un autre. » Cette délégation casse les modèles d'identité classiques, et fait apparaître un problème de fond : « le contexte d'exécution — utilisateur d'origine, agents intermédiaires — est perdu d'un saut à l'autre », rendant l'audit incomplet. La réponse d'Uber est entièrement déterministe : des jetons à usage unique et de courte durée, une chaîne d'acteurs vérifiable de bout en bout — [utilisateur, agent-1, agent-2] —, une identité cryptographique adossée à des standards ouverts (SPIFFE/SPIRE, OAuth 2.0 Token Exchange). Et un point clé pour démentir le procès en lourdeur : la latence P99 de ce service d'identité reste sous les 40 millisecondes à l'échelle de milliers d'agents. Opérer des agents en production sans effondrer la redevabilité, c'est possible — mais cela s'architecture, cela ne s'espère pas. Sur le déploiement et l'exploitation eux-mêmes, voir notre article sur l'aval du cycle.

Faire avancer la frontière, plutôt que la nier

Une frontière n'est pas un mur. Ce qui est hors-périmètre aujourd'hui le sera moins demain — à condition de travailler dans le bon ordre. Quelques leviers concrets, pour un décideur.

D'abord, gouverner la donnée avant d'agentiser. Pas après, pas « en parallèle » : avant. Cartographier les données, les droits, les juridictions, et choisir une chaîne d'hébergement dont on connaît les exigences — une qualification comme SecNumCloud n'est pas une case réglementaire, c'est ce qui débloque légalement l'usage agentique sur des données sensibles.

Ensuite, sur le certifiable, viser l'IA comme renfort de V&V et qualifier la chaîne d'outils par étapes. On ne bascule pas d'un coup un processus DO-178C ou EN 50128 vers l'autonomie. On commence par ajouter l'IA là où elle ne signe rien — un angle de revue supplémentaire, une détection de régression de plus — tout en faisant mûrir, séparément et formellement, la qualification des outils. La frontière recule au rythme de cette qualification, pas au rythme des modèles.

Troisième levier, séparer la génération et l'assurance. C'est la recommandation explicite de Sonar : l'outil qui écrit le code ne doit pas être celui qui le teste et le valide, sous peine de reconduire ses propres biais. La preuve gagne en valeur quand elle vient d'ailleurs que de l'auteur.

Enfin, pour les agents qui passent en production, traiter leur identité comme on traite celle d'un humain : zero-trust, jetons éphémères, provenance traçable. Le modèle d'Uber montre la cible ; la doctrine d'adoption qui l'accompagne — « le chemin sûr doit être le plus facile pour le développeur » — montre la méthode pour qu'elle soit réellement suivie.

La maturité, c'est de nommer ses limites

Revenons à l'écart du début : 64 % d'intentions, 17 % de déploiements réels. Ce fossé ne se comblera pas par un modèle plus intelligent. Il se comble par de la gouvernance et de la preuve — exactement les deux choses qu'un meilleur modèle ne fournit pas.

C'est le parti pris de SFEIR avec sa stratégie AI for IT : viser un facteur dix, mais sous discipline de preuve, et se l'appliquer d'abord à elle-même — l'objectif affiché est de 850 consultants augmentés par l'IA, en interne, avant tout déploiement client. Cette honnêteté de périmètre n'est pas une prudence frileuse. C'est l'inverse : c'est ce qui rend l'approche déployable. Un fournisseur qui promet l'IA partout, tout de suite, vend le rêve qui finit en projet annulé d'ici 2027. Un partenaire qui vous dit où l'on va — back-offices, APIs, modernisation de legacy, volume traçable — et où l'on ne va pas encore — l'inédit sans intention tranchée, le certifiable sans chaîne d'outils qualifiée, les données non gouvernées — vous donne une carte sur laquelle décider.

La bonne question n'a jamais été « l'IA en est-elle capable ? ». Elle était, et reste : où votre chaîne sait-elle prouver ce qu'elle produit ? Là où elle le sait, allez-y franchement. Là où elle ne le sait pas encore, ne forcez pas la frontière : gouvernez, qualifiez, prouvez — et regardez-la reculer.

Cet article fait partie d'une série sur le SDLC augmenté. Voir le pilier — le cycle SFEIR à 11 phases, l'amont (Define & Plan), l'aval (Ship, Ops, Deprecation), la revue à l'ère de l'IA et la convergence des cadres (ADLC).

Sources

1. SFEIR — SDLC augmenté par l'IA : le cycle à 11 phases et la stratégie AI for IT, matière first-party, 2026.
2. DO-178C, Software Considerations in Airborne Systems and Equipment Certification — norme (avionique).
3. EN 50128, Applications ferroviaires — Logiciels pour systèmes de commande et de protection ferroviaire — norme (ferroviaire).
4. Rippletide, Agent reliability: What's missing in Enterprise AI agent architecture? — rippletide.com, 29 octobre 2025.
5. Edgar Kussberg, AI in the SDLC: Cutting Through the Hype — aijourn.com, 15 septembre 2025.
6. Arthur Mensch (Mistral AI), Audition devant la commission d'enquête de l'Assemblée nationale sur les vulnérabilités numériques — youtube.com, 13 mai 2026.
7. Uber Engineering, Solving the Identity Crisis for AI Agents — uber.com, 21 mai 2026.