AI4IT d'abord : pourquoi l'IA pour le SI précède l'IA pour les métiers

Le DSI qui investit dans l'IA pour les métiers hérite seul des problèmes

Fin 2025, la plupart des annonces stratégiques positionnaient 2026 comme l'année de l'AI4Business : l'intelligence artificielle générative appliquée aux processus commerciaux, marketing, service client, ressources humaines. Six mois plus tard, les conversations en comité de surveillance, en comité stratégique DSI et lors des dîners C-level racontent une autre histoire. L'IA pour les métiers a glissé à 2027 minimum. Un autre chantier prend toute la place : AI4IT, l'IA appliquée au système d'information lui-même.

La raison est moins technologique que politique. Le DSI qui engage ses équipes sur de l'IA for business voit le ROI s'écrire ailleurs — dans les comptes de la direction commerciale, dans les tableaux de bord du marketing, dans les objectifs annuels des directions métiers. Les coûts d'infrastructure, les risques de sécurité, la dette technique, la gouvernance des données restent sa responsabilité. La gloire part au business, les problèmes restent à l'IT. Plusieurs DSI interrogés ces dernières semaines ont formulé la même observation : investir d'abord pour les autres est un pari qui se paye cher.

À l'inverse, AI4IT — aussi appelé AI for IT ou IA pour le build et le run du SI — produit un ROI direct, interne à la DSI, mesurable avec des indicateurs que l'IT maîtrise : temps de développement, coût par fonctionnalité, vélocité de delivery, taux de couverture de tests, mean-time-to-repair. Les sociétés de service IT qui accompagnent les DSI grands comptes, comme SFEIR, observent le même basculement chez leurs clients : le premier budget IA à engager n'est plus destiné aux métiers, il est destiné à l'IT lui-même.

AI4IT contre AI4Business : deux horizons, deux économies politiques

La distinction mérite d'être posée proprement, parce qu'elle structure les feuilles de route des trois prochaines années. AI4IT désigne l'application de l'IA générative et agentique au système d'information lui-même : écrire du code, générer des tests, refactorer des bases, déployer, observer, diagnostiquer des incidents, remédier automatiquement. Les utilisateurs sont les équipes IT ; les bénéfices vont à l'IT. AI4Business désigne l'application de l'IA aux processus front-office — chatbots de relation client, assistants commerciaux, agents de support, génération de contenu marketing, copilotes pour les collaborateurs métiers. Les utilisateurs sont les directions métiers ; les bénéfices aussi.

Ce découpage n'est pas strictement hermétique — un copilote qui assiste un commercial utilise des briques techniques qui relèvent de l'IT — mais la ligne de crédit budgétaire, le sponsor, le KPI de succès et la personne qui défend l'investissement devant le Comex changent radicalement. Quatre raisons expliquent pourquoi l'économie politique de 2026 pousse AI4IT en premier :

• Un ROI direct et interne : un développeur qui gagne en vélocité, un ingénieur d'exploitation qui raccourcit son MTTR, un architecte qui accélère une migration — ce sont des chiffres que la DSI mesure dans ses propres outils et qu'elle peut présenter sans négociation interservices.
• Une asymétrie politique réelle : en période de contrainte budgétaire, le DSI qui déploie de l'IA pour les autres avant d'en déployer pour lui-même ne pèse pas les mêmes arguments dans les arbitrages.
• Une maturité organisationnelle inégale : les directions métiers, dans beaucoup d'organisations, ne sont pas prêtes à absorber une transformation agentique de leurs processus — les règles de qualification, les workflows, les référentiels ne sont ni formalisés ni suffisamment documentés pour qu'un agent puisse s'y intégrer.
• Des outils matures côté développement : Claude Code, Cursor, Gemini for Workspace, Copilot, sans oublier le protocole MCP qui standardise l'accès des agents aux outils de dev, forment une pile cohérente et stabilisée, là où les outils d'IA pour les métiers restent fragmentés, verticaux, souvent immatures.

Conséquence concrète observée : les DSI rationnels basculent leur priorité sur l'IA pour l'IT comme première marche, en se donnant un horizon 12-18 mois avant d'ouvrir sérieusement le chantier AI4Business.

Dev, Ops, Run : trois segments, trois maturités

AI4IT n'est pas un bloc monolithique. Les trois grands périmètres de l'IT — développement logiciel, opérations, exploitation — se comportent très différemment face à l'IA agentique. Les confondre dans un plan unique mène à des déceptions.

Dev en 2026 : la marche déjà franchie

Le segment Dev est le premier à avoir basculé. Les DSI sont alignés, les stacks sont stabilisées, les retours d'expérience sont documentés dans la plupart des grandes organisations. Des tâches qui demandaient vingt heures il y a un an sont aujourd'hui réalisées en quatre heures ; le coût par fonctionnalité livrée est divisé par dix à cent selon la nature du travail. Ces chiffres ne sont plus hypothétiques — ils sont visibles dans les tableaux de bord internes des équipes qui ont adopté sérieusement les outils.

Quatre mécanismes expliquent ces gains :

• La complétion intelligente qui anticipe l'intention du développeur bien au-delà de l'autocomplétion syntaxique.
• La génération de tests automatisée qui réduit drastiquement le coût de la couverture qualité.
• Les agents de refactoring capables de comprendre une base de code entière et d'y appliquer un pattern de transformation cohérent.
• Le Model Context Protocol qui standardise la manière dont les agents accèdent aux outils de développement, aux systèmes de fichiers et aux APIs internes.

La question n'est plus de savoir si AI4IT améliore le développement. C'est de savoir comment industrialiser ces gains — Compound Engineering comme cadre méthodologique, Context Engineering comme discipline, Harness Engineering comme ingénierie du système autour de l'agent.

Ops en 2026-2027 : la frontière à débloquer

Le segment Ops — pipelines de déploiement, observabilité, infrastructure as code, gestion des environnements — reste la frontière. Les DSI hésitent. Les raisons sont connues : complexité réglementaire (ISO 27001, DORA, NIS2), obligations contractuelles en SLAs, runbooks encore largement tacites, exigences de traçabilité sur les changements en production. Tant qu'un agent ne peut pas produire un audit trail équivalent à celui d'un opérateur humain, l'ouverture se fait avec prudence.

C'est pourtant là que la bascule se prépare. La logique qui pousse : dès lors que les outputs de Dev sont produits à la vitesse d'un AI4Dev industrialisé, les goulots se déplacent vers Ops. Une équipe Dev qui livre dix fois plus de changements par semaine sature sa CI/CD, ses environnements de staging, ses revues de configuration. L'IA appliquée aux opérations devient nécessaire — non pas pour remplacer les ingénieurs d'exploitation, mais pour maintenir l'équilibre entre une production de code accélérée et une capacité d'intégration qui, elle, n'a pas changé.

Le déblocage attendu en 2026-2027 viendra par les organisations qui auront su industrialiser leur Dev assez vite pour que le gap Ops devienne insoutenable. Elles n'auront pas le choix.

Run à partir de 2027 : l'horizon agentique

Le segment Run — exploitation courante, supervision, remédiation d'incidents, FinOps — est plus lointain. Les promesses sont énormes : agents qui diagnostiquent automatiquement une alerte, qui proposent un correctif avant qu'un ingénieur n'ait lu le ticket, qui réallouent des ressources en fonction du coût horaire d'un cloud. Mais ces promesses supposent une maturité Ops en amont. On ne remédie pas automatiquement sur une infrastructure dont les runbooks ne sont pas écrits. On ne fait pas de FinOps agentique sans tagging strict des ressources.

L'ordre logique — Dev, puis Ops, puis Run — n'est donc pas arbitraire. Il reflète une dépendance technique. Les organisations qui brûlent les étapes échouent proprement : elles tentent du Run agentique sur un Ops immature, et reviennent discréditées à l'IT avec l'étiquette "l'IA ne marche pas ici".

AI4IT rebat les cartes du build-vs-buy

Un effet de second ordre d'AI4IT, souvent sous-estimé, concerne l'équation build-vs-buy. Pendant deux décennies, l'argument dominant a été : ne reconstruisez pas, achetez un progiciel, c'est moins cher et c'est maintenu. Cet argument supposait un coût de construction élevé. Quand ce coût est divisé par dix, l'équation s'inverse partiellement.

Trois dynamiques s'enclenchent simultanément. D'abord, le build redevient compétitif : une organisation qui connaît précisément son besoin peut développer sur mesure sans payer l'obésité fonctionnelle d'un progiciel qui vise dix secteurs à la fois. Ensuite, des entrants ultra-rapides peuvent reconstruire from scratch un concurrent établi en quelques mois — la barrière à l'entrée logicielle s'est effondrée pour ceux qui savent manier les agents. Enfin, même les organisations qui ne refont pas possèdent désormais un levier de négociation crédible face aux éditeurs historiques : la menace de tout refaire tire les prix vers le bas.

Les éditeurs de logiciels sont donc pris en tenaille. Leur modèle de valeur reposait sur la ligne de code produite — qui vaut moins aujourd'hui. Pour rester compatibles avec les agents qui opèrent côté client, ils doivent ouvrir leurs APIs et exposer leurs surfaces fonctionnelles. Mais plus une API est ouverte, plus elle devient orchestrable par un tiers, plus l'éditeur perd son rôle central. L'ouverture complète de la surface API de Salesforce en avril 2026 a marqué le signal public de cette bascule : le plus gros éditeur SaaS du monde a accepté d'exposer tout ce qu'il fait pour rester compatible agent, au risque d'accélérer sa propre désintermédiation.

Pour la DSI, ce rebat offre une fenêtre rare : repenser son portefeuille applicatif en séparant la vraie commodité (qu'on achète) du vrai différenciant (qu'on construit avec AI4IT). C'est un exercice que beaucoup de DSI ont renoncé à faire depuis dix ans, faute de capacité de build compétitive. Cette capacité revient.

Test de maturité : le site web comme premier agent

Comment une DSI sait-elle qu'elle est prête à engager sérieusement AI4IT — au-delà du pilotage expérimental et des POCs qui s'accumulent ? Un test simple, pragmatique, est utilisé par plusieurs équipes qui ont pris de l'avance : remplacer le CMS du site public par un agent autonome capable de générer et publier du contenu.

Le site web est un périmètre faible, à impact faible, mais qui exige les briques fondamentales de l'agentique : un contexte versionné, des guides explicites, des sensors de validation, des guardrails éditoriaux, une boucle de feedback. Si une organisation ne sait pas faire ça, elle ne saura pas faire des agents plus complexes sur des périmètres plus critiques. Inversement, l'organisation qui a franchi ce test a construit une stack AI-Ready et une SDLC augmentée qui lui serviront pour tous les chantiers suivants.

Un second test, plus culturel, consiste à mesurer la proportion de projets où l'IA est acceptée comme méthode de production. Une organisation qui ne l'accepte que sur 10 % de ses projets n'est pas prête à AI4IT. Ce ratio est un indicateur de la dette culturelle — peut-être le risque le plus sous-estimé de la fenêtre 2026-2027.

Les risques : fenêtre d'apprentissage courte, dette culturelle, dépendance aux éditeurs IA

AI4IT n'est pas un pari sans ombre. Plusieurs risques structurants méritent d'être posés plutôt que d'être lus en filigrane plus tard, quand ils se matérialisent.

Le premier est celui d'une fenêtre d'apprentissage courte. Pendant les dix-huit premiers mois, les organisations qui adoptent l'IA pour l'IT ont le droit de se tromper — le marché comprend que c'est nouveau. Passé cette fenêtre, les écarts de productivité entre concurrents deviennent visibles, mesurables, exploitables commercialement. Les acteurs en retard ne pourront plus se permettre d'erreurs d'apprentissage : le décalage sera trop visible, les attentes trop élevées.

Le deuxième est la dette culturelle. Les équipes qui n'ont pas fait l'effort d'adoption en 2026 ne pourront pas rattraper en 2028. Les méthodes de travail, les critères de qualité, les rituels d'ingénierie changent quand l'IA entre dans le flux — et ces changements ne s'apprennent pas par un cours de deux jours. Ils s'acquièrent par la pratique répétée, dans un contexte où l'IA est vraiment intégrée à la production, pas cantonnée à des bacs à sable.

Le troisième est l'obésité cognitive : la tentation de multiplier les outils, les agents, les copilotes, les plateformes — et de perdre le focus méthodologique qui fait la différence entre une adoption qui produit des gains et une adoption qui produit du bruit. Mieux vaut un outillage resserré et une méthode commune qu'une profusion de solutions concurrentes.

Le quatrième est la dépendance aux éditeurs d'IA. Miser son AI4IT sur un seul fournisseur de modèles crée un lock-in stratégique aussi coûteux à défaire que les lock-ins ERP des années 2000. Les contrepoids connus sont le multi-modèle au niveau de l'architecture agentique, les couches d'abstraction via MCP, l'infrastructure souveraine (Scaleway, S3NS) pour ne pas mettre toutes ses données dans un pipeline américain, et les plateformes agentiques internes qui exposent l'intelligence de l'organisation derrière une API maîtrisée.

Le cinquième, plus contre-intuitif, est l'écart de staffing. AI4IT ne réduit pas le nombre d'ingénieurs requis — il change leur profil. Les équipes traditionnelles de huit personnes (pizza teams) cèdent la place à des équipes sandwich resserrées, où un Product Engineer augmenté couvre la majorité de la chaîne, entouré de contributeurs ponctuels. Recruter et former ces profils est aujourd'hui un goulot plus serré que l'accès aux modèles.

Leviers d'action pour la DSI en 2026-2027

Au-delà des diagnostics, quelques leviers concrets structurent les feuilles de route DSI qui avancent vite sans se disperser.

Refuser l'amélioration continue, viser les sauts ×5 et ×10

Les gains de 5 % ou 10 % sur une tâche sont absorbés par l'inertie organisationnelle — la revue de code, la validation, les réunions d'arbitrage. Seuls les sauts ×5 et ×10 obligent l'organisation à réorganiser son flux, à supprimer des rituels devenus caducs, à redistribuer les responsabilités. La cible doit être posée haut. Des gains ×100 sur la génération de contenu ou la refonte d'un site public sont désormais documentés sur des cas réels — et ce plafond continue de monter.

Industrialiser avec une méthode transversale, pas une accumulation de POCs

Le piège classique est l'accumulation de POCs : chaque équipe teste un outil, produit un rapport, range le tout dans un tiroir. Aucun apprentissage ne se compose. Le remède : une méthode commune — comme Compound Engineering — qui formalise la boucle Plan → Work → Review → Compound, où chaque cycle enrichit le suivant et où la courbe de complexité descend à mesure que la courbe de vélocité monte.

Construire une capacité de production différente, pas la même en plus rapide

Dans ce cadre, plusieurs sociétés de service IT, dont SFEIR, assument un positionnement de rupture : Factory augmentée livrée en engagement de résultat, refus des projets où l'IA n'est pas acceptée comme méthode de production, capacité de production équivalente à dix fois le nombre de consultants dans l'ancien monde, et appui sur les frameworks Compound Engineering, Context Engineering et Harness Engineering comme socle méthodologique. Les partenariats avec les éditeurs d'IA (Anthropic notamment) et avec les infrastructures souveraines (Scaleway, S3NS) structurent un jeu à plusieurs étages plutôt qu'une dépendance unique.

Former des Product Engineers, pas seulement des utilisateurs d'IA

La compétence qui compte en 2026 n'est pas "savoir prompter". C'est savoir concevoir un système où un agent est productif : architecturer le contexte, rédiger des conventions qui tiennent, instrumenter des sensors de qualité, documenter les invariants métier, revoir la sortie d'un agent avec la même rigueur qu'on reviewait un junior. Ce métier a un nom — Product Engineer — et il est à former, pas à acheter, parce qu'il mélange des compétences que le marché externalise rarement au même endroit.

Conclusion : AI4IT n'est pas une option technologique

AI4IT — l'IA pour le build et le run du SI — n'est pas un chantier parmi d'autres. C'est la condition d'exercice du métier de DSI dans la fenêtre 2026-2027. Les organisations qui reportent l'adoption ne se contentent pas de prendre du retard sur une courbe d'apprentissage : elles prennent une dette culturelle que leurs concurrents n'auront pas, sur une fenêtre d'arbitrage qui se refermera vite.

La phrase qui revient le plus souvent dans les cercles de DSI avancés, attribuée à Didier Girard, résume le pari : "Il faut qu'on arrête de penser qu'on est 1 000, il faut qu'on pense qu'on est 10 000, parce qu'on doit créer dix fois plus de valeur avec l'IA. Si on ne le fait pas, on est mort." La formule est brutale, mais elle n'est pas isolée. C'est l'ordre de grandeur qui change — pas l'équation, pas les outils, pas les compétences individuelles : l'ordre de grandeur de ce qu'une organisation peut produire avec les mêmes ressources humaines. Les DSI qui intègrent cette nouvelle unité de mesure dans leur feuille de route 2026-2027 parlent un langage différent de ceux qui restent dans la recherche de 5 % marginaux.

AI4Business viendra. Elle viendra probablement en 2027, une fois que l'IA pour l'IT aura créé dans chaque organisation la stack, la méthode, la culture et les profils nécessaires pour attaquer sérieusement les processus métiers. Mais il faudra y arriver par AI4IT — pas à côté.