L’IA introduit-elle une rupture dans les modèles d’affaires des ESN ?

le 27/01/2026 par Sylvain Fagnent

Tags: Data & AI, Software Engineering, No Code / Low Code, Intelligence Artificielle

1 - Introduction

L’art du développement logiciel ne connaît pas une évolution, il vit une révolution voire une rupture. L’IA générative en est à l’origine. Juste pour illustrer, deux éléments parmi d’autres qui factualisent ce qui se passe aujourd’hui dans le développement logiciel : le nombre de questions posées sur Stack Overflow a chuté fortement depuis le lancement de ChatGPT en novembre 2022. Et selon le Developer Survey 2025 de Stack Overflow, 84% des développeurs utilisent désormais des outils d'IA dans leur travail.

Chez Octo, l’IA n’est plus un simple outil performant de recherche d’information comme pouvait l’être Stack Overflow. Nous l’utilisons désormais de manière continue et systématique comme un moteur puissant d’analyse et de production de code. Cela nous amène naturellement à nous interroger sur l’impact que cette évolution pourrait avoir sur la façon de concevoir et de mener des projets informatiques.

En particulier, en tant qu’ESN, ne pourrait-on pas voir apparaître en face de nous de nouveaux acteurs aux business modèles disruptifs dont des modèles low cost ? Quels profils recruter alors et/ou comment les former ? Assiste-t-on à une innovation de rupture qui bouleverse les modèles d'affaires de tout un secteur, ou bien est-ce (juste ?) une transformation accélérée de nos modèles ?

Nous analyserons l’impact de ces usages et pratiques sur nos propres modèles d’affaires. Nous verrons que les effets sont bien réels. Mais jusqu’où serons-nous alors chahutés ? Chacun pourra ainsi se projeter dans son propre univers d’ESN. Une chose est sûre : la traversée s’annonce très agitée.

Note : Pour un rappel historique des évolutions fulgurantes de l’IA au cours de ces 3 dernières années, c’est par ici par notre collègue Nicolas Cavallo.

L’impact de l’IA sur le modèle d’affaire des ESN: mais jusqu’où allons-nous être chahutés ? (Illustration réalisée avec Gemini)

2 - Définitions

2.1 RPV (Ressources, Process et Valeurs)

Avant de répondre à la question “rupture or not rupture”, il est important de comprendre quelques concepts qui entrent en jeu lors d’une innovation de rupture. Pour cela je reprends les notions de RPV (Ressources, Process et Valeurs) que l’on retrouve par exemple dans l’ouvrage “Relevez le défi de l’innovation de rupture” de Philippe Silberzahn.

Ressources: ce sont les actifs dont l'organisation a besoin pour délivrer la proposition valeur. C’est ce qui représente l’avantage concurrentiel se rapportant souvent aux choses uniques que fait l'entreprise avec ses ressources
Processus: ce sont les modalités de travail qui transforment un actif entrant en un actif sortant. Il s’agit du savoir-faire de l'entreprise.
Valeurs: ce sont les principes auxquels on doit se conformer, manières d'être, agir. Principes qu'une collectivité reconnaît comme idéals. Ils définissent comment sont déterminées les priorités de l'entreprise au quotidien.

En quelques lignes pour OCTO (évitons trop l’auto-promotion ;-)) qu’est ce que cela signifie

Ressources : L’expertise des consultants et leur savoir être
Processus : Les savoirs méthodologiques et techniques
Valeurs :
- Une communauté d’experts passionnés…
- …constamment à la recherche d’une meilleure façon d’agir, de nouveaux savoir-faire et de nouvelles problématiques auxquelles apporter des solutions nouvelles
- Des artisans du sur mesure, intransigeants sur la qualité
- Une expertise entretenue qui se vend chère
- Un accompagnement des profils juniors

2.2 Le modèle d'affaire

Un modèle d’affaire est la logique globale par laquelle une entreprise crée, délivre et capture de la valeur. Les composantes sont la proposition de valeur, formule de profit (comment l’entreprise gagne de l’argent) associés aux ressources, processus et valeurs (RPV) qui permettent de délivrer cette proposition. Le modèle d’affaire relie donc ce que l’entreprise offre, la manière dont elle s’organise en interne et la façon dont elle monétise cette offre.

Lorsqu’il y a rupture, il y a avant tout rupture du modèle d'affaire, les RPV de l'entreprise entrent en contradiction avec le nouveau modèle. Le nouveau modèle n’a aucun sens pour l’entreprise en place voire il peut y avoir un rejet culturel / éthique (valeurs) de l’entreprise.

Le modèle d’affaire relie l’offre, son organisation et sa monétisation associées (Illustration réalisée avec Gemini)

3 - Les modèles d'affaire évoluent

3.1 Delivery : le coût global de la phase de développement baisse

Sur les aspects projets de développement pur, nous sommes encore en phase d’apprentissage - l’absence de recul sur un nombre de projets suffisants, dans des contextes suffisamment variés et sur des tailles significatives ne nous permet pas d’établir des évaluations / roadmaps fiables qui incluraient l'IA dans la boucle des outils à disposition. On sait que les équipes gagnent en productivité. Et dans un projet de delivery, si l’on considère que l’on gagne en productivité, le coût global de la phase de développement baisse.

L’impact est donc direct pour une ESN comme Octo. L’expertise autour de l’IA, vendue chère parce qu’encore rare, contrebalance bien sûr mais elle n’est que temporaire - la montée en expertise va aussi progresser sur le marché au fil du temps, faisant ainsi baisser les TJM). Cette expertise encore rare peut d’ailleurs être commercialisée lors de missions de conseil méthodologiques et/ou techniques.

3.2 Les missions se déplacent vers la reprise en main d’applications legacy

3.2.1 L’IA accélère la compréhension de l’existant et le refactoring

Le modèle d’affaire peut en effet changer si les missions évoluent (se déplacent). La reprise en main d’applications legacy en est une potentielle illustration. Pourquoi ?

Parce que les IAs permettent de comprendre et documenter vite un code existant avec génération de commentaires ou descriptions de modules et rendu de diagrammes de séquences. Elles permettent de réduire fortement le temps d’« onboarding ». Elles permettent aussi d’extraire des règles métier et de comportement à partir du code et d’exemples. Elles permettent la cartographie par analyse des dépendances entre modules / services pour identifier les zones critiques, les couplages forts et les effets de bord éventuels. Bien sûr, elles détectent la duplication de code, les anti‑patterns, les faiblesses de performance ou de sécurité (à prioriser à la reprise).

La limite principale : nécessité d’un important travail de cadrage, de stratégies de recherche et de prompts. Fort ROI donc sur la base d’un investissement important.

Elles autorisent alors le refactoring: extraction de méthodes, découpage de fonctions, introduction d’interfaces, voire une conversion vers un framework ou un langage plus moderne. Et bien entendu, elles permettent l’indispensable à tout refactoring i.e. la génération de jeux de tests unitaires ou d’intégration à partir du code existant. Point d’attention : toujours encadrer l’IA par une stratégie de tests systématique (tests de non‑régression) et des revues de code humaines, car les IAs introduisent des erreurs en particulier en mal interprétant le contexte métier ou les consignes passées.

L’IA accélère la compréhension de l’existant et le refactoring (Illustration réalisée avec Gemini)

3.2.2 La reprise en maîtrise technique et financière de son parc applicatif enfin possible

On peut alors aisément imaginer que les missions de type reprise/refonte de legacy vont augmenter au détriment (en tout cas si l’on reste à budget constant) des nouveaux développements. Les clients peuvent voir dans ce type de missions une opportunité tant espérée de reprise en maîtrise de leur parc applicatif, avec des gains financiers grâce à une baisse des coûts de maintenance.

Le parc applicatif legacy en mal de maîtrise dont les coûts de maintenance chaque année embarrassent la DSI, est immense (évolution coûteuse, tests de non régression manuel interminable et à la fiabilité aléatoire). C’est d’autant plus intéressant que cela contribue également à limiter les effets du turnover et à réduire les situations de SPOF (Single Point of Failure), encore trop fréquentes dans les équipes. Quant aux ESN qui fondent leur position sur une logique d’incontournabilité liée à la maîtrise d’applicatifs, elles pourraient bien avoir quelques raisons de s’inquiéter à long terme ;-).

l'IA facilite la reprise ou la refonte d'applications legacy (Illustration réalisée avec Gemini)

3.3 Lors des due diligences techniques, les investisseurs prennent désormais en compte les chantiers de refactoring

Rappel: Lors d’un investissement ou d’un rachat d’une entreprise technologique, l'évaluation de la partie IT ne devrait plus être un élément de seconde zone, les risques de déboires sont avérés. Les fonds ou entreprises ayant investi dans des entreprises dites technologiques mais sans prendre connaissance des sous-jacents techniques, s'en mordent les doigts quelques années plus tard au moment de la revente. Au moment de la revente, lorsqu’un cabinet comme OCTO Technology vient faire l’audit; patatra, les red flag peuvent tomber, le deal n’est pas forcément retardé, ni même annulé mais des chantiers IT finalement conséquents car non anticipés sont à mener et la valorisation finale est impactée.

A l’aide de l’IA, lancer les chantiers IT pour reprendre les assets techniques pourraient ne plus être aussi impactants. Il nous arrivait aussi qu’on nous demande d’estimer le coût de récriture des assets techniques en nous posant la question: “à dire d’experts, si vous deviez les développer vous mêmes, quelle serait la fourchette de prix ?” Sur la base de différentes méthodes et de notre expertise en delivery nous arrivions à répondre à cette question. Avec l’IA dans la boucle, la question pourrait revenir plus systématiquement. Pour le moment, les retours d’expérience en reprise de legacy sont trop peu nombreux pour qu’on puisse donner une quelconque fourchette mais à terme, la question reviendra régulièrement. Enfin, d’un point de l’analyse/audit strict, l’IA va accélérer voire élargir le diagnostic.

Les investisseurs prennent désormais en compte les chantiers de refactoring (Illustration réalisée par O.Morvan)

3.4 Les audits de sécurité sont facilités

Une automatisation d’analyse autour des failles de sécurité par une IA qui cracke / trouve des failles dans le code, génère des scripts pour exécuter des tests d’intrusion sur une application, fait des recommandations correctives, il y a une opportunité à accélérer ce type d’activité, surtout si l’on est pas spécialiste, cela peut jouer le rôle d’un premier niveau d'évaluation.

4 - De nouveaux entrants pourraient bien nous chahuter

4.1 Innovation de rupture et nouvel entrant

S’il y a rupture, elle se caractérise par une asymétrie de motivation entre les acteurs en place et de potentiels nouveaux entrants. Ces derniers, sans héritage ni contraintes historiques, se positionnent sur des marchés de niche peu ou pas attractifs pour les acteurs établis. Ceux-ci jugent ces marchés sans intérêt, car ils ne correspondent pas à leurs RPV.

4.2 Pas de rupture dans les modèles d'affaires des ESN pour le moment…mais ça va tanguer sévère !

Pour le moment, il n’y a pas de rupture au sens strict d’une rupture de modèle d’affaire. En revanche, comme disent souvent mes collègues “ça va sérieusement tanguer” et chambouler les missions auxquelles les ESN étaient habituées jusqu’ici. De plus, de nouveaux acteurs peuvent clairement faire leur apparition avec des business modèles dérivés des anciens qui s’appuieront sur des compétences aux formes nouvelles. Les équilibres d’organisation, des compétences et donc des talents changent. A plus long terme ça se discute….mais c’est plus difficile d’y voir clair car tout n’est pas sec. Les modèles d’affaires des fournisseurs d’IA ne sont pas encore stabilisés, et la lisibilité quant à la nature et à la forme des compétences qui seront nécessaires à terme sont encore en construction.

Perturbation en vue dans les modèles d’affaire des ESN (Illustration réalisée avec Gemini)

4.2.1 Apparition de structures plus légères en équipes réduites et spécialisées

De la sorte, des structures plus légères, en équipes réduites et spécialisées (sur un domaine métier par exemple) pourraient voir le jour. Elles pourraient être aussi spécialisées sur la reprise de code legacy. L’appétence du marché me semble se porter de ce côté-ci; en tout cas les signaux actuels me le laissent penser - cf. missions et AO que l’on commence à recevoir. Les clients perçoivent déjà les gains en maintenabilité. Enfin, retrouver la maîtrise d'applications anciennes puis de leur évolution et/ou de leur sortie deviennent désormais atteignables. Et ça, ce n’est pas rien. Les gains financiers aussi sont perçus car il faudrait moins d'ETP pour maintenir les applications y compris sur le run.

L’IA dans le développement logiciel permet l’émergence de structures plus légères, en équipes réduites et spécialisées sur la reprise de code legacy (Illustration réalisée avec Gemini)

4.2.2 L’arrivée d’acteurs plus low cost

Un autre chamboulement pourrait pointer son nez, avec l’arrivée d’acteurs plus low cost. Toujours au sein de structures plus légères, ces nouveaux acteurs pourraient articuler leur organisation autour de quelques profils seniors — voire de juniors formés selon de nouvelles formes d’apprentissage (cf. chapitre Risques) — ainsi que de développeurs peut-être moins expérimentés, mais disposant de la capacité à évaluer un code. Des profils pour lesquels la production de code n’est plus nécessairement une fin en soi ni une activité particulièrement attractive pour eux.

Ces ingénieurs et techniciens supérieurs du code pourraient trouver une grande satisfaction (motivation) à travailler dans des environnements dont les équipes ont pour objectifs de résoudre des problèmes client sur la base de logiciel; mais sans pour autant être des experts du code. On a déjà croisé ce type de postures notamment avec les approches NCLC (NoCode LowCode). Des profils, suffisamment techniques mais non informaticiens dans l’âme se sont appropriés les outils NCLC pour construire des applications. Certains, comme Charles Thomas (comet.co) avaient d’ailleurs réussi à aller loin dans la démarche.

Note : attention “low cost does not mean low quality”. Ikea, Decathlon, EasyJet voire Lidl, toutes ces marques ont une très bonne réputation. Bien que low cost, elles ne sacrifient rien sur la qualité de leur produit ou service cœur.

4.2.3 Les vieux développeurs reviennent dans le “game”

Moins réactif mais meilleur en conception, en prise de hauteur, en anticipation, en configuration, en résolution de problème, le “vieux” développeur sénior pourrait bien revenir dans la partie. La production du code n'est plus un frein pour lui malgré son coût en tant que profil très expérimenté. Très qualifié, son efficacité vis à vis du code sera dans sa vérification en sortie d’IA. Le tandem IA / “vieux” développeur trouve un équilibre économique qu’on n’ imaginait plus à priori. C’est dans les vieux pots qu’on fait les meilleures soupes; ce vieux dicton ne trouvera pas meilleure résonance que dans ce contexte ;-).

Note : un autre profil comme le développeur indépendant pourrait lui aussi tirer son épingle du jeu car grâce à l’IA il pourrait couvrir un périmètre plus large.

Les vieux développeurs reviennent dans le “game” (Illustration réalisée avec Gemini)

4.2.4 Les clients ont moins besoin d’ESN et deviennent plus autonomes

Dès lors que

le code tend à devenir un actif proche de la commodité,
les IAs deviennent de plus en plus fiables,
les gains de productivité apportés par l’IA sont déjà significatifs,
la maintenance est simplifiée grâce à l’IA (compréhension, documentation, tests, …),

les entreprises pourraient être incitées à s’appuyer d’avantages sur des équipes internes resserrées, au plus près des métiers, s’appuyant sur l’IA pour produire elles-mêmes les logiciels attendus.

Nos clients sont plus aisément en mesure de constituer des équipes internes correctement dimensionnées, resserrées et composées de profils expérimentés maîtrisant ces nouveaux modes de fonctionnement. Dès lors, dans quelle mesure auront-ils encore besoin de mobiliser de “grosses” équipes de développeurs issues d’ESN pour mener des chantiers de développement ? Par ailleurs, la logique d’arbitrage purement fondée sur le TJM entre onshore et offshore perd de sa pertinence : une équipe outillée par l’IA peut désormais produire, à effectif réduit, ce qui nécessitait auparavant des équipes plus nombreuses dépourvues de ces outils

Toutefois, nous ne pensons pas que les entreprises puissent se passer totalement des ESN, ne serait-ce que parce qu’elles leur offrent une capacité de ressources, mobilisables et démobilisables rapidement (par exemple en cas de crise). À l’instar du NoCode/LowCode (NCLC), l’IA va permettre à des équipes moins techniques de concevoir des logiciels, qu’ils soient expérimentaux ou pérennes. La DSI aura alors besoin d’être accompagnée pour maîtriser l’afflux de nouveau code généré — sans oublier les enjeux liés au shadow IT. Par ailleurs, certaines organisations continueront à externaliser ces compétences lorsqu’elles ne relèvent pas de leur cœur de métier ou simplement parce que ce n’est pas dans leur culture… et la culture évolue toujours lentement ;-).

Les clients deviennent autonome et utilisent l'IA au sein de petites équipes au plus près du métier (Illustration réalisée avec Gémini)

4.3 Souveraineté, une opportunité pour un nouvel entrant

Aujourd’hui, pour les acteurs (ESN) en place qui visent une efficacité opérationnelle, utiliser des solutions purement souveraines est un frein. Effectivement, les solutions d’IA les plus performantes restent majoritairement américaines. Une alternative souveraine existe néanmoins avec l’acteur français Mistral, encore en phase de montée en puissance et qui n’atteint pas encore le niveau de maturité de ses concurrents américains. La bonne nouvelle pour la souveraineté est que Mistral vient de signer un accord avec le ministère des Armées qui a choisi d’utiliser sa solution pour déployer l’intelligence artificielle dans ses services ce qui devrait lui permettre de se développer peut être plus rapidement.

On pourrait croire qu’il s’agit également d’une barrière à l’entrée pour un nouvel acteur. Toutefois, s’il existe une asymétrie de motivation entre les acteurs en place et un entrant potentiel : ce dernier, dépourvu d’historique, peut se concentrer sur un marché de niche qui n’intéresse que marginalement les acteurs (ESN) établis. Il peut alors transformer cette contrainte en opportunité, par exemple en nouant un partenariat avec un acteur souverain européen ou français comme Mistral, ou en investissant dans des alternatives aux solutions américaines dominantes.

Ainsi, quelles autres alternatives se profilent ? Elles sont encore émergentes mais d’ici 1 ou 2 ans elles seront probablement matures.

Souveraineté, une opportunité pour un nouvel entrant (Illustration réalisée avec Gemini)

4.3.1 Alternative : le serveur onPremise

La première des alternatives serait d’utiliser des serveurs “onPremise”. De la sorte on se met plus facilement en conformité au RGPD, on assure une meilleure confidentialité, on anticipe mieux les coûts car prévisibles et on doit pouvoir s’appuyer sur des modèles d’IA OS. Les inconvénients de cette approche tient dans un coût initial élevé (cf. serveurs GPU), une maintenance en infrastructure, un besoin de compétence technique et la performance en dessous des meilleurs modèles cloud du moment.

4.3.2 Alternative : AWS Bedrock en Europe

Une alternative moins poussée consiste dans l’utilisation de AWS Bedrock en Europe. AWS Bedrock permet d’accéder facilement à des modèles de langage (LLM) et à d’autres modèles depuis une API unifiée.

Au lieu de déployer et maintenir ses propres modèles et gérer des clusters GPU ou serveurs, on utilise une API serverless et le cloud AWS gère la performance, la scalabilité, la sécurité sur la base de modèles provenant de plusieurs fournisseurs (ex. Anthropic, Cohere, Meta, Mistral, etc.).

Les données restent sous son contrôle et ne servent pas à ré‑entraîner les modèles de base. Un ajustement d'un modèle (fine‑tuning), AWS crée une copie privée du modèle pour son usage : les données ne sont pas partagées avec les fournisseurs de modèles et ne sont pas utilisées pour améliorer les modèles. Les données envoyées sont chiffrées en transit et au repos, et restent dans son compte AWS, sous les propres politiques d’accès du client. Les données ne sont pas exposées aux autres clients. C’est un bon compromis.

4.3.3 Alternative : API LLM sur Cloud souverain (OVH, Scaleway, Cloudscale)

Les fournisseurs de cloud souverain comme Scaleway ou OVH exposent maintenant des modèles de langage (LLM) as a service via une API hébergée sur leurs clouds souverains. Cela permet de conserver la souveraineté des données, la conformité réglementaire et une indépendance vis-à-vis des acteurs extra-européens. La limitation est la puissance des modèles proposés (open source).

4.3.4 Alternative : Pure player souverain comme Mistral

Face aux acteurs dominants américains de type OpenAI ou Claude, des acteurs souverains “pure player” (Mistral) sont en train d’émerger. Mistral mise ainsi sur une approche open source pour plusieurs de ses modèles et propose une API pour s’intégrer facilement sans avoir à gérer l’infrastructure sous-jacente. Enfin, Mistral facilite le respect des réglementations européennes comme le RGPD.

5 - Risques

5.1 Laisser les juniors sur le bord du chemin

Dans les sujets qui fâchent, il est un fait établi qu’à date sur ce type d’approche seuls les développeurs seniors profitent de cette nouvelle voie. Plusieurs études montrent que les postes en informatique destinés habituellement aux développeurs juniors diminuent ou sont plus difficiles à obtenir. Une tendance de fond est que les entreprises embauchent moins de jeunes ingénieurs car l’utilisation d’assistants de codage par IA rend moins nécessaire de former des juniors sur des tâches basiques.

Le vivier de seniors n’est pas éternel (départ en retraite, etc.), donc le flux d’une manière ou d’une autre doit être maintenu.

Le risque de laisser les juniors sur le bord du chemin (Illustration réalisée avec Gemini)

5.1.1 Mitigation: l’IA plus mentor que béquille

Par conséquent, il faut évoluer sur les tâches confiées aux profils junior et sur la manière dont on les forme (à l’université ou en école) et les fait grandir en entreprise.

Une façon d’apprendre pour les juniors serait d’encadrer l’IA et pas seulement lui faire faire des tâches basiques qu’ils faisaient par eux mêmes avant comme par exemple les tests. A l’école ou en entreprise, la phase d’apprentissage sera différente.

Développer une forme d’apprentissage, dans laquelle l’IA devient un mentor et moins une béquille. L’objectif est qu’ils acquièrent une réelle capacité à évaluer un code produit. Par rapport à un élève d’avant l’arrivée de l’IA, la quantité de code à laquelle ils seront exposés sera nettement plus importante : les exercices et TP disponibles seront bien plus nombreux et plus facilement accessibles grâce à l’IA, avec en outre des interactions et des corrections en temps réel.

Quelques règles d’or pour bien apprendre avec l’IA:

Toujours lire et comprendre le code généré et sur les parties de code non compris demander des explications
Évaluer par rapport une documentation officielle du langage
Tester sa compréhension du code en le “cassant” volontairement; c’est utile pour en comprendre son fonctionnement
Et évidemment, accepter que l’IA se trompe parfois…même si cela va être de moins en moins vrai

Un bon chemin d’apprentissage pour un junior pourrait être par exemple

Résoudre seul → être bloqué ;-)
Demander de l’aide à une IA,
1. en lui expliquant son raisonnement et lui demander pourquoi ça bloque ?
2. lui demander comment résoudre (mais sans écrire le code) et discuter jusqu'à ce que ce soit compris
Récupérer et comprendre le code que l’IA produit
Challenger la solution et lui demander de proposer des alternatives
Si c’est votre mode de mémorisation, réécrire le code de mémoire
Ajouter des tests et des améliorations

D’une certaine manière, cet apprentissage pour “notre junior” emprunte désormais un autre chemin. Pour autant, il repose toujours sur les mêmes mécanismes fondamentaux : l’apprentissage par essais-erreurs et par mimétisme. Ce sont précisément ces boucles itératives qui permettent une montée en compétence réelle. Tout n’est donc pas perdu ;-)

Pour les juniors, utiliser l'IA comme un mentor plutôt que comme une béquille (Illustration réalisée avec Gémini)

5.2 Par fainéantise systématiquement passer par une IA

Des dernières discussions que j’ai pu avoir avec mes collègues, la phase de vérification en sortie d’un agent va vite devenir obsolète tant la fiabilité couplée à l’expertise des consultants au niveau du prompt rend cette étape caduque; je n’aurai pas écrit ces lignes il y a 1 an !! Produire du code deviendrait alors une commodité !

Je l’ai déjà évoqué, s’arrêter d’écrire du code soi-même, pour les seniors c’est potentiellement perdre ses réflexes et la maîtrise du geste avec un risque d’asservissement et d’érosion des compétences. Pour les profils juniors, qui se contenteraient de copier/coller cela ne leur permettrait pas de les faire grandir. Sur le long terme ce n’est pas tenable**. Je reste persuadé qu’on apprend bien par le geste.** En prenant sans analyse ce que retourne l’agent, je crains qu’on frôle le syndrome d’un apprentissage à faire du vélo sans jamais enlever les roulettes stabilisatrices ou bien d’apprendre à marcher avec un trotteur (très mauvais pour l’apprentissage de la marche chez les enfants).

Comparaison n’est pas raison, certes mais on ne retient et acquiert une compétence que par la pratique, ce sur quoi on a passé du temps. Ce sur quoi on a pu se tromper (tomber). Je cite de nouveau Hegel (1770–1831), philosophe du XVIIIe et XIXe siècle ! « Si l'apprentissage se bornait à une simple réception, le résultat n'en serait guère meilleur que si nous écrivions des phrases sur l'eau ; car ce n'est pas la réception, mais l'auto-activité par laquelle on se saisit de quelque chose, et la faculté d'utiliser, à nouveau, une connaissance, qui, seules, en font notre propriété » (src).

Métaphore : par fainéantise on se laisser porter par l’automatisation et on ne sait plus marcher tout seul (Src: film animation Wall-E)

5.2.1 Mitigation : parfois on prompt parfois on code

Pour les juniors : Voir point précédent

Un développement logiciel “hand-craft” sur le core domaine métier, et qui permet de plus de garder ses compétences, qui serviront ensuite pour comprendre et améliorer ce que produit l’agent. On code avec un agent les sujets dont seul le résultat importe, les “trucs” rébarbatifs. Idem, avec l'IA on bâtit les composants très génériques/standards ou encore pour de l’introspection de services/API en mode découverte par brute-force, l’IA construit ainsi le client pour accéder aux services. Cela change tout de même des habitudes, y compris aujourd’hui, puisque une partie de leur temps les équipes de développement prompteront les IAs et valideront leurs productions….comme un contremaître du code ou un contrôleur qualité en bout de ligne. Choc culturel garanti pour tout le monde !

De toute façon, on ne désinvetera pas le coding à base d’agent. “Deal with it” ;-) On peut alors aussi profiter de l’IA comme un outil pédagogique (ex : expliquer du code, proposer des alternatives). Il faut alterner les méthodes: réserver des projets ou des modules sans IA pour maintenir les compétences et organiser des revues de code collaboratives pour discuter des codes générés en équipe pour enrichir la compréhension collective.

Alors tu codes ou tu promptes ? (Illustration réalisée avec Gemini)

5.3 Le shadow IT et l’explosion du parc applicatif

Si produire des applicatifs grâce à l’IA devient de plus en plus accessible à des non informaticiens purs et durs y compris pour des applications évoluées on risque de voir apparaître une explosion du parc d’applications hors DSI - le fameux shadow IT. Les DSI ont déjà connu cette vie par le passé (Excel dans les années 2000 et les applications VB, puis le NoCode plus récemment).

Il leur faudra alors reprendre ses codes et/où accompagner les équipes en support pour à minima les aider dans leur conception, limiter la dette technique ou encore éviter les failles de sécurité. Alors certes les IAs leur faciliteront la tâche de reprise mais le risque c’est qu’elles soient submergées de nouveaux codes à reprendre. Le goulot d’étranglement n’est plus la production, mais la reprise, la gouvernance et la sécurisation. L’IA réduit le coût marginal de production, pas celui de la responsabilité.

Explosion du parc d’applications hors DSI - le fameux shadow IT (Illustration réalisée avec Gemini)

5.3.1 Mitigation : une filière support pour accompagner les “citizens dev”

Organiser une filière qui implique la mise en place d’une cellule support qui accompagne, forme et aide ces “citizens developers” à être “meilleur” dans leur autonomie. Cette approche permet de mutualiser les efforts et les coûts en ressources humaines IT pour développer la version finale des applications. La cellule concentre ses efforts sur des présentations/formations, diffusion des bonnes pratiques, définition des standards, outillage, audits, sécurisation, reprise du code si nécessaire, voire par délégation accompagne au sein des équipes dans la durée. La DSI passe de “producteur” à “architecte du cadre de production”.

Attention toutefois la cellule support risque elle-même de devenir un SPOF si la demande explose trop vite, ou si les règles ne sont pas suffisamment automatisées. Il est probable que la mitigation devra elle aussi être augmentée par l’IA, sinon elle ne passera pas à l’échelle.

5.4 Faire transiter du code sensible/stratégique sur des clouds non souverains

Un code sensible/stratégique peut par exemple contenir des algorithmes propriétaires, clés d’API, des mots de passe, une architecture critique, des failles de sécurité non corrigées, etc.). En le faisant transiter vers un LLM hébergé sur un cloud non souverain, on s’expose au fait que le code peut être consulté voire réquisitionné par des autorités d’états tiers étrangers (cf. le Cloud Act américain). On crée ainsi un risque de fuite ou d’accès non maîtrisé à son code, qui est alors stocké en dehors de son SI et peut être réutilisé pour l’entraînement de modèles ou exposé accidentellement (fuite de données, vulnérabilités des LLM).

5.4.1 Mitigation : cf. “Souveraineté, une opportunité pour un nouvel entrant”

5.5 L’explosion des coûts de licence

Quelle que soit le fournisseur d’IA, on ne sait dire quels modèles économiques il choisira, ni s’il a une chance d’être rentable à court ou moyen terme. Les coûts d’entraînement, d’infrastructure et d’utilisation restent massifs, la compétition impose encore une logique de “cash burn”.

Les prix actuels ne sont donc pas représentatifs de l’avenir et la probabilité pour qu’ils augmentent fortement en tout cas pour les entreprises est proche de 1. Donc si en tant qu’ESN un plan d’utilisation est prévu dans les missions de delivery - à date on tourne aux alentours de 20€ / jour et par développeur en mode intensif - il faut envisager que demain cela puisse être multiplié par 2, 5 voire 10.

L’explosion des coûts de licence (Illustration réalisée avec Gemini)

5.5.1 Mitigation : cultiver son indépendance et provisionner du cash

N’oubliez pas qu’on est LLM indépendant, c’est probablement la meilleure arme de protection (une assurance stratégique) qui puisse exister actuellement. En cas d'augmentation tarifaire gênante et non contrôlée, on peut soit débrancher instantanément et repasser temporairement en mode sans IA (la décélération est brutale mais il n’y a pas de crash), soit on envisage une migration d’outillage (autre IA). Cette dernière implique une gestion du changement et une complexité opérationnelle propre aux environnements multi-LLM — qualité variable, prompts peu portables, comportements différents — mais elle ne relève en aucun cas d’un plan de migration étalé sur plusieurs années.

Enfin, utiliser plusieurs outils est toujours un plus dans la maîtrise d’un éco-système rapidement mouvant. Ce qui est sûr est qu’aucune entreprise ne devrait se retrouver comme par le passé dans des situations de dépendance (euphémisme) comme lors de migration ou de montée de version des ERPs, des clouds managés (trop) ou encore des framework propriétaires.

D’autre part, il est prudent de provisionner du cash. Bien malin qui pourrait dire combien mais ne pas le faire est risqué. A chacun d’évaluer le niveau de couverture souhaité, sachant que ce coût doit pouvoir être facturé lors des prestations. Il faut donc aussi prévoir des clauses de réévaluation des coûts de licence dans les contrats et encore plus en cas de forte volatilité tarifaire.

Enfin, une autre piste consiste à envisager des modèles internes et open, par exemple via des déploiements on-premise de modèles spécialisés. Cette approche est plus lourde, plus longue à mettre en œuvre et potentiellement déceptive en termes de performance, mais elle reste une option crédible — et, honnêtement, nous avons déjà traversé par le passé des situations bien plus inconfortables.

LLM indépendant, c’est probablement la meilleure arme de protection stratégique (illustration réalisée avec Gemini)

6 - Conclusions

6.1 La production de code n’est plus un différentiateur

Dès 2026, on peut estimer que le code produit ne sera plus l’élément clé de différenciation : il tendra à devenir une commodité. L’enjeu principal reste et restera toujours dans la capacité qu’auront les équipes à produire un code maintenable. Grâce aux IA, cela devient de plus en plus facile, sans dépendance à un éditeur en particulier — “LLM indépendant”. Le code ainsi produit pourra être réutilisé directement par les équipes en place, par de futures équipes ou même par un autre LLM, si nécessaire.

6.2 Moins de développeurs dont des profils moins techniques

Les ressources nécessaires à la production de code assistée par l’IA évolueront, tant en volume qu’en proportion, notamment dans le ratio entre ingénieurs et “techniciens du code” — avec, à terme, un impact sur les stratégies de recrutement. La rupture n’est toutefois pas aussi brutale que celle qu’a connue Kodak dans les années 2000 : nous ne vivons pas un “instant Kodak” (voir note “L’instant Kodak”). Les profils dont nous disposons aujourd’hui sont en effet capables d’évoluer et de se reconvertir, à ressources constantes.

En revanche, à plus long terme, une modification du ratio ingénieurs / techniciens du code — profils qui n’existent pas encore réellement aujourd’hui — pourrait changer la donne. Avec des profils moins techniques, il devrait désormais être possible d’accomplir ce qui nécessitait auparavant des équipes plus nombreuses et plus expertes, qu’elles soient onshore, nearshore ou offshore

L’instant Kodak : la rupture tient au fait qu’historiquement, l’entreprise commercialisait des pellicules et leur développement sur papier. Avec le passage au numérique, ce modèle disparaît et la photo numérique n’implique plus de développement physique et les utilisateurs ne font même plus tirer leurs clichés. Par conséquent, les usines et les laboratoires deviennent inadaptés à la nouvelle demande (processus). Du point de vue des ressources humaines, Kodak aurait alors eu besoin d’électroniciens plutôt que de chimistes (ressources). C’est ce que l’on qualifie d’« instant Kodak » : jusqu’en 2003, l’entreprise voit encore ses bénéfices croître, avant de s’effondrer dès l’année suivante et d’entamer sa descente aux enfers.

Avec le passage au numérique, les usines et les laboratoires historique de Kodak deviennent inadaptés à la nouvelle demande (Illustration réalisée avec Gemini)

6.3 Conservez la maîtrise du geste des seniors et formez les juniors

S’arrêter d’écrire du code soi-même, pour les seniors c’est potentiellement perdre ses réflexes et la maîtrise du geste avec un risque d’asservissement et d’érosion des compétences. Pour les profils juniors, continuez à les recruter et apprenez leur comment pratiquer le code avec IA (en attendant que les écoles et universités s’y mettent ;-), - voir chapitre Risques) et sans IA même si vous deviez sacrifier un peu de productivité, l’investissement est rentable. Je reste persuadé qu’on apprend bien par le geste et les études sur le sujet tendent à me donner raison. Enfin, n’oublions pas que les juniors sont les futurs séniors !

Utiliser l’IA et conserver la maîtrise du geste (Illustration réalisée avec Gemini)

6.4 Commencez par les audits et la reprise de code legacy (brownfield), enchaînez vite par le greenfield

Pour rester dans la course à plus long terme, quelles propositions de valeur et quels modèles d’affaires les ESN devront-elles faire évoluer ou inventer ? Comment faire face à l’émergence de nouveaux acteurs, qu’ils soient internes chez les clients ou externes, au sein de structures plus petites et spécialisées ? C’est dès maintenant qu’il faut y réfléchir… et agir.

Par où commencer ? Par les audits et/ou la reprise de code legacy (brownfield) : de ce côté-là, le vivier d’activités potentielles est déjà conséquent. Ce sont également des missions propices pour éprouver la prise en main de ces outils et permettre aux clients de mesurer concrètement le potentiel d’amélioration — et d’économies — qu’on peut en retirer, tout en réduisant les risques organisationnels liés à la présence de SPOF au sein de leurs équipes.

Et ne tardez pas à enchaîner rapidement avec des projets de développement greenfield : l’autre composante essentielle pour rester dans la course est d’intégrer la vitesse de progression des LLM. De l’avis des experts, ce que l’on constate aujourd’hui était encore impensable il y a à peine un an ; il subsistait alors des limites auxquelles il fallait pallier (manuellement, plusieurs itérations, …). La vitesse de progression étant fulgurante, les progrès significatifs en matière de performances des agents ne se comptent plus en années, mais seulement en mois.

6.5 Ne misez pas sur l’éclatement de la bulle

Enfin, ne pas se lancer en misant sur un éclatement de la bulle car il existe clairement une euphorie et des excès autour de l’IA, n’est pas raisonnable. Certes, les investissements dans l’IA (notamment générative) ont explosé depuis 2020, avec des valorisations parfois déconnectées de leurs revenus actuels ou de leurs profits attendus. C’est effectivement assez typique d’une bulle spéculative. Mais, malgré tous ces excès, l’IA restera un moteur structurel de productivité et d’investissement et de fait actuellement en phase de surchauffe. On ne fera pas disparaître l’IA en cas de correction: ce sont surtout certaines valorisations et projets non viables qui pourraient être écartés. Rappelez vous que quelle que soit l’IA que vous utilisez, vous restez indépendants vis à vis d’elle (“LLM indépendant”). Cela signifie que contractuellement, il y a zéro risque à choisir un éditeur plutôt qu’un autre. Votre coût de sortie et de migration est pratiquement nul ! Ca aussi c’est assez nouveau dans le monde de l’IT et c’est clairement un élément accélérateur dans l’adoption !!

Ne misez pas sur l'éclatement de la bulle spéculative des investissements (Illustration réalisée avec Gemini)

6.6 Géopolitique : ce que personne ne maîtrise vraiment

Quels éditeurs parviendront à rester dans la course, indépendamment même de l’idée d’un vainqueur ? Quels modèles économiques leur permettront de dégager des revenus ? Quelles postures adopteront les États-Unis et l’Europe dans un contexte de tensions économiques potentielles — voire probables ? C’est précisément pour cette raison qu’il devient stratégique d’envisager sérieusement et/ou travailler de concert avec des acteurs souverains (et open source) européens, actuels et futurs.

Enfin, la rupture est peut être ailleurs. “L’IA générative chinoise gagne du terrain en dehors des marchés occidentaux. En Afrique, en Asie, les modèles « low cost » et ouverts développés par DeepSeek séduisent les utilisateurs bien davantage que les modèles américains, chers et fermés, d’OpenAI ou de Google.” (source 01). Certains pourraient s’en inspirer et choisir ce type d’acteurs et faire une percée très low cost.