25 ans dans le build, un constat : la valeur passe de la construction au pilotage

Votre IA est déployée. Qui la pilote ?

J'ai passé vingt-cinq ans à vendre du build.

J'ai cofondé et développé un groupe de conseil et de services numériques : plus de 1 000 collaboratrices et collaborateurs, des plateformes livrées sur quatre continents, puis la cession à un groupe confrère. Le modèle qui a porté cette croissance tenait en une équation simple : les entreprises ont besoin de construire plus de logiciel qu'elles ne savent en produire, et cette rareté se facture à la journée.

Cette équation vient de se briser. Et je préfère l'écrire moi-même plutôt que de faire semblant de ne pas le voir : l'IA va absorber la majorité des capacités de build des entreprises. Pas une part marginale, pas les tâches ingrates : la majorité. Qu'on le veuille ou non.

La bascule est déjà chiffrée

Ce n'est plus une prospective. Satya Nadella déclarait dès avril 2025 que 20 à 30 % du code présent dans les dépôts de Microsoft était désormais écrit par l'IA, et la courbe ne redescendra pas. Les agents de développement autonomes enchaînent aujourd'hui des tâches qui occupaient des équipes entières : spécification, génération, test, refactoring, documentation. Près de neuf organisations sur dix utilisent désormais l'IA dans au moins une fonction.

Chaque DSI le constate dans ses murs : un développeur augmenté produit ce que produisait une petite équipe. Un métier outillé assemble en quelques jours ce qui exigeait un projet. La production de logiciel, ce goulot d'étranglement qui a justifié quarante ans d'ESN, de forfaits et de régie, est en train de devenir abondante.

Or l'économie ne pardonne jamais à l'abondance : ce qui devient abondant cesse d'être cher, et cesse d'être stratégique. Le build suit le chemin du calcul et du stockage avant lui. Il ne disparaît pas. Il se banalise.

Le paradoxe que personne n'assume

On pourrait croire que cette abondance produit mécaniquement de la valeur. Les chiffres disent l'inverse, avec une brutalité rare.

Gartner prévoyait qu'au moins 30 % des projets d'IA générative seraient abandonnés après le proof-of-concept d'ici fin 2025 ; le même cabinet anticipe l'annulation de plus de 40 % des projets d'IA agentique d'ici fin 2027. Le MIT, sur plus de 300 initiatives analysées, mesure qu'environ 5 % des pilotes seulement génèrent une accélération rapide de valeur. Et McKinsey résume l'ensemble d'une phrase : neuf organisations sur dix utilisent l'IA, 37 % en voient un impact sur leur résultat.

Jamais les entreprises n'ont autant construit. Jamais si peu de constructions n'ont produit de valeur.

Ce paradoxe a une explication que le marché regarde encore peu : nous avons industrialisé la production, pas l'exploitation. Tout, les budgets, les compétences, les partenaires, les indicateurs, reste organisé autour de l'acte de construire, au moment précis où construire cesse d'être le problème. Les plateformes sont là. Personne ne sait les faire voler.

La ruée, puis le pilotage

Regardez ce qui s'est passé chez vous depuis trois ans. Une fonction d'IA s'est activée dans la suite bureautique à la faveur d'une mise à jour, sans que personne ne l'ait demandée. Un agent a été monté en trois jours par une direction métier. Un assistant s'est glissé dans le CRM, un autre dans l'outil de tickets, un troisième dans l'ERP. Dès 2024, trois cadres et employés de bureau sur quatre utilisaient l'IA au travail, et la plupart avec leurs propres outils. Chacun de ces outils fait quelque chose. Personne n'en répond.

Ce n'est pas une faute, c'est une ruée, et toutes les technologies qui ont compté ont connu la leur. Mais la ruée touche à sa fin, et ce qui vient ensuite est inévitable : des IA sous surveillance humaine, inventoriées, mesurées, dont quelqu'un répond. Ce n'est plus seulement ma conviction, c'est la loi : depuis le 2 août 2026, dire aux gens qu'ils s'adressent à une machine n'est plus une courtoisie, c'est une obligation (article 50 de l'AI Act), et la surveillance humaine des systèmes à risque incombe à l'entreprise qui les déploie, pas seulement à l'éditeur qui les vend (articles 14 et 26).

Ce que l'aviation a compris avant nous

Quand l'automatisation est entrée dans les cockpits, certains ont prédit la fin des pilotes. Il s'est produit exactement l'inverse : le métier s'est déplacé. Le pilote moderne touche à peine le manche ; il architecture un plan de vol, surveille des instruments, gère des procédures, arbitre des exceptions. Et sa responsabilité n'a jamais été aussi grande, précisément parce que le système est devenu trop complexe pour être piloté « à la main ».

L'aviation a converti l'automatisation en sécurité parce qu'elle a inventé, en même temps que l'autopilote, la discipline de sa supervision : instruments normalisés, check-lists, seuils d'alerte, revue systématique des incidents, culture de la fiabilité mesurée.

C'est très exactement ce qui manque au système d'information augmenté. L'IA nous a donné l'autopilote du build. Personne n'a encore construit le cockpit.

Le DSI, architecte et pilote

Voici donc ma conviction, celle que vingt-cinq ans du côté des constructeurs m'autorisent à formuler : le DSI qui réussira la décennie ne sera plus un maître d'ouvrage du build. Il sera l'architecte et le pilote d'un cockpit.

Architecte, d'abord : quand la production devient abondante, ce qui devient rare, c'est le dessin d'ensemble. Décider ce qui doit exister, ce qui doit s'interfacer, ce qui doit rester humain. L'architecture cesse d'être une phase de projet pour devenir la fonction permanente qui empêche l'abondance de produire du chaos, car un système où chacun peut construire est un système qui dérive par défaut.

Pilote, ensuite. Un cockpit digne de ce nom affiche en continu cinq cadrans, et je connais peu de comités de direction qui sachent les lire aujourd'hui :

1. Fiabilité. Quels pipelines, quels agents, quels rapports sont dignes de confiance, mesuré en continu, pas constaté après incident par les utilisateurs.
2. Coûts. La consommation réelle des capacités et des modèles, pilotée comme le carburant, pas découverte sur la facture.
3. Preuves AI Act. Le registre des systèmes, leur classe de risque, les obligations applicables, les responsables nommés et les preuves datées, documentés en marche, pas reconstitués sous la contrainte d'un contrôle.
4. Utilisation. L'usage réel de ce qui a été construit, par qui, et ce qu'il rapporte, car un actif non utilisé est une pure perte que l'abondance rend indolore, donc invisible.
5. Référentiels. Le savoir de l'entreprise qui alimente les systèmes, entretenu comme un actif, parce qu'un modèle nourri d'un savoir périmé produit des erreurs avec une assurance parfaite.

Et comme dans un cockpit, l'humain n'intervient plus partout : il intervient là où la confiance du système est insuffisante. C'est le renversement du modèle de servuction que j'ai pratiqué toute ma carrière : non plus des hommes assistés par des outils, mais des systèmes supervisés par des experts, déclenchés par des seuils. Des experts qui connaissent la plateforme de l'intérieur, et qui ne vous ont rien vendu d'autre.

Ce que cela déplace, ce que cela crée

Soyons honnêtes sur les conséquences, y compris pour mon ancien métier.

Le modèle de l'intégrateur, vendre des jours-homme pour construire, ne survivra pas tel quel à l'abondance. Mais ce n'est pas le métier qui se banalise, c'est l'une de ses tâches. L'expertise, elle, devient plus rare et plus précieuse : quand n'importe qui peut faire produire un agent en trois jours, la valeur se déplace vers ceux qui savent dire s'il est digne de confiance, le mettre à l'épreuve, le tenir en production, et en répondre. Le consultant senior qui a livré dix ans de Salesforce, de SAP ou de Microsoft ne disparaît pas ; il change de siège, du chantier vers le cockpit, et sa valeur augmente, comme celle de tous les acteurs du domaine qui savent faire voler ce que d'autres ont construit. C'est autour de ces fonctions que nous construisons 56North : le cockpit lui-même, déjà livré ; des partenaires pour la mise à l'épreuve humaine et l'exploitation, en cours de constitution ; et un réseau d'experts seniors issus des communautés de praticiens de chaque plateforme. Ce sont eux qui piloteront.

Une seule condition, que l'aviation a posée avant nous : le constructeur ne certifie pas ses propres appareils. La reconversion de l'intégrateur vers « l'IA managed services » bute sur ce conflit : on ne peut pas être juge et partie, mesurer sereinement la fiabilité de ce qu'on a soi-même construit et facturé. Construire et contrôler doivent rester deux métiers séparés, même quand les mêmes experts savent faire les deux.

Trois fonctions vont donc concentrer la valeur : ceux qui dessinent (les architectes du système augmenté), ceux qui pilotent (les opérateurs du cockpit, avec leurs instruments et leurs seuils), et ceux qui mesurent (les tiers indépendants capables de dire, chiffres à l'appui, si une plateforme vole ou fait semblant). L'électricité a créé l'ingénierie électrique, le cloud a créé les Cloud Operations, la cybersécurité a créé le SOC. La discipline d'exploitation de l'intelligence n'a pas encore de nom établi. Elle aura ses référentiels, ses scores, ses centres d'exploitation, et ses pionniers.

Le danger, le conseil

Le danger	Le conseil
Des fonctions d'IA se sont activées dans vos outils à la faveur de mises à jour. Personne ne sait combien il y en a, ni qui en répond.	Dressez le registre de toutes vos IA en service, y compris celles livrées par vos éditeurs, avec pour chacune un responsable nommé.
La fiabilité d'un agent se découvre quand un utilisateur se plaint.	Mesurez la qualité des réponses en continu, sur les échanges réels, avec des seuils d'alerte écrits à l'avance.
Le coût des modèles se découvre sur la facture, en fin de mois.	Suivez la consommation par système et par usage, et fixez un budget par agent, comme on gère un carburant.
Les preuves exigées par l'AI Act seront reconstituées à la hâte le jour d'un contrôle.	Documentez en marche : classe de risque, obligations applicables, preuves datées, au fil de l'eau et non a posteriori.
Celui qui a construit vos IA est aussi celui qui vous dit qu'elles fonctionnent.	Séparez construire et contrôler : confiez la mesure à un tiers qui ne vous a rien vendu d'autre.

L'appel

Aux DSI qui me lisent, et aux dirigeants qui signeront un jour le registre de leurs IA, une seule question, celle que je poserais à mon propre comité de direction : votre IA est déployée. Qui l'opère ? Pas qui l'a construite. Qui la fait voler, avec quels instruments, quels seuils, et quelles preuves, datées, qu'un contrôleur acceptera. Si la réponse est un silence, ou « notre intégrateur, je suppose », vous connaissez maintenant votre chantier de la décennie.

Le build augmenté n'est pas une menace pour les DSI. C'est leur promotion, à condition d'accepter de changer de siège : quitter celui du donneur d'ordres qui achète de la construction, prendre celui du commandant de bord qui répond de la trajectoire.

J'ai passé vingt-cinq ans à vendre la construction. Je passerai les suivantes à construire le cockpit.

Pascal Mennesson, cofondateur de Maltem Consulting Group, fondateur de 56North. Vous êtes dirigeant et vous souhaitez en parler : demandez un premier échange.