Le 25 août 2026, McKinsey a publié son enquête annuelle « The State of AI ». Un chiffre a retenu l'attention des équipes techniques : 32 % des organisations interrogées déclarent avoir renoncé à acheter au moins un logiciel, ou une fonctionnalité, parce qu'elles pouvaient le construire en interne avec des outils de codage agentique1. L'enquête repose sur 1 719 répondants dans le monde, interrogés entre le 4 mai et le 8 juin 2026.
Pour une PME ou une ETI qui vit sur Odoo et sur une pile de SaaS, ce chiffre pose une question concrète. Faut-il continuer à payer un abonnement pour chaque brique manquante, ou coder soi-même ce qui manque avec l'aide d'un agent ?
Qui construit, et pourquoi
Le mouvement n'est pas uniforme. McKinsey observe que les décisions de « construire plutôt qu'acheter » viennent surtout de la tech et de la santé, puis des services professionnels et de l'énergie. Elles se concentrent aussi chez les entreprises déjà avancées. Parmi les « high performers », ces 6 % de répondants qui attribuent au moins 5 % de leur EBIT2 à l'IA, près de la moitié disent avoir sauté un achat logiciel, contre 31 % pour le reste du panel.
Ce sont donc les organisations déjà outillées, celles qui savent exploiter un agent de code3, qui internalisent le plus. La bascule tient à une évolution technique bien réelle. Un agent de code sait aujourd'hui lire une base existante, générer un module, écrire ses tests et proposer un correctif. Le coût marginal d'une fonctionnalité sur mesure baisse. Quand ce coût passe sous celui d'un abonnement annuel augmenté de son intégration, l'arbitrage se déplace.
Le coût qui ne figure pas sur le devis
La même enquête pose un garde-fou. Environ une organisation sur cinq déclare limiter son usage de l'IA à cause des coûts d'exploitation, coûts de tokens4 compris. Et l'industrialisation reste prudente : à peine deux organisations sur dix disent passer des agents de code à l'échelle, une part qui monte à 31 % dans les grandes entreprises.
Ce point mérite l'attention d'un dirigeant de PME. Le devis d'un développement interne s'arrête à la livraison. La facture réelle, elle, continue. Un module maison doit être maintenu à chaque montée de version d'Odoo, et corrigé dès qu'une dépendance casse. Sa sécurité reste votre affaire, année après année. Le code produit par un agent n'échappe pas à cette règle.
| Poste de coût | Acheter un SaaS ou un module | Construire avec un agent de code |
|---|---|---|
| Mise en route | Abonnement et paramétrage | Spécification, génération, coûts de tokens |
| Maintenance | Portée par l'éditeur | À votre charge à chaque version |
| Sécurité | Mutualisée entre clients | À auditer en interne |
| Reprise du code | Documentée par l'éditeur | Dépend de votre équipe |
| Adaptation au métier | Limitée au paramétrage | Totale |
Ce que cela change pour une pile Odoo
Odoo est un bon terrain pour cet arbitrage, parce que la frontière entre acheter et construire y est déjà floue. L'Apps Store propose des milliers de modules payants, et le framework se prête à l'écriture de modules internes. Un agent de code modifie la pente de la seconde option.
Prenons un cas courant. Une PME veut un connecteur entre Odoo et un outil métier de niche. Elle peut acheter un module à quelques centaines d'euros par an, ou demander à un agent de générer un module d'intégration à partir de la documentation de l'API. La seconde voie devient tenable pour une équipe qui n'a pas de développeur Odoo à plein temps. Elle suppose en revanche une revue humaine sérieuse, des tests, et quelqu'un capable de reprendre le code six mois plus tard.
Le piège consisterait à lire le chiffre de McKinsey comme un feu vert général. Les 32 % recouvrent surtout des fonctionnalités ciblées, pas le remplacement d'un ERP ou d'un CRM entier. Personne ne recode Odoo avec un agent.
Notre lecture
Le basculement décrit par McKinsey est réel, mais il récompense la discipline plutôt que l'enthousiasme. Un agent de code abaisse le coût de la première ligne, il ne supprime pas le coût de la dixième année. Pour une PME sur Odoo, la bonne question n'est donc pas « puis-je le coder ? », mais « suis-je prêt à le maintenir ? ».
Nous appliquons une règle simple. Nous construisons quand la fonctionnalité est spécifique au métier et stable dans le temps, parce qu'aucun éditeur ne la couvrira jamais correctement. Nous achetons quand la brique est standard et évolue vite, parce qu'un éditeur amortit sa maintenance sur des milliers de clients. L'agent de code élargit le premier cas sans effacer le second. Le même débat traverse le marché du logiciel d'entreprise, comme nous l'écrivions à propos de la SaaSpocalypse.
Le chiffre à surveiller sur les douze prochains mois ne sera pas le taux d'entreprises qui construisent, mais celui de celles qui, dix-huit mois plus tard, regretteront de ne pas avoir acheté.
Sources
- McKinsey, The State of AI: Global Survey 2026 (25 août 2026) : https://www.mckinsey.com/capabilities/quantumblack/our-insights/the-state-of-ai
- The Register, « McKinsey says enterprise AI is finally 'on the road to ROI' » (25 août 2026) : https://www.theregister.com/ai-and-ml/2026/08/25/mckinsey-says-enterprise-ai-is-finally-on-the-road-to-roi/
- TechTimes, « Record AI Spending Can't Move Earnings Needle for 94% of Enterprises, McKinsey Finds » (26 août 2026) : https://www.techtimes.com/articles/325590/20260826/record-ai-spending-cant-move-earnings-needle-94-enterprises-mckinsey-finds.htm
Footnotes
-
Codage agentique : usage d'un agent logiciel qui, à partir d'une consigne, planifie et exécute plusieurs étapes de développement (lecture du code, génération, tests, correctifs) avec une intervention humaine réduite. ↩
-
EBIT : résultat d'exploitation avant intérêts et impôts, indicateur de la rentabilité opérationnelle d'une entreprise. ↩
-
Agent de code : outil d'IA générative spécialisé dans l'écriture et la modification de code, capable d'agir sur un dépôt existant plutôt que de produire de simples suggestions ligne à ligne. ↩
-
Token : unité de texte facturée par les modèles d'IA, à l'entrée comme à la sortie. Le coût d'un agent dépend directement du volume de tokens consommés. ↩