La réponse courte
Près d'un tiers des organisations — 32% — ont renoncé à acheter au moins un produit ou une fonctionnalité logicielle parce qu'elles pouvaient le construire en interne avec des agents IA de code, selon le rapport The State of AI in 2026 de McKinsey publié le 25 août 2026. Le virage est le plus marqué chez les plus performantes, où près de la moitié a refusé un achat. Mais la même couverture souligne une vérité difficile : les systèmes construits en interne n'ont historiquement réussi qu'environ un tiers du temps, contre environ deux tiers pour les logiciels éditeurs. Les outils de codage agentiques réduisent le coût de la première version — pas le coût de possession. Les équipes qui gagnent ce virage sont celles qui associent la vitesse de l'IA à une vraie discipline de développement logiciel sur mesure.
Ce que dit vraiment l'enquête
L'enquête annuelle State of AI de McKinsey, sous-titrée cette année On the road to ROI, s'est déroulée du 4 mai au 8 juin 2026 et a recueilli 1 719 réponses dans 97 pays. Le résultat qui a retenu l'attention du secteur : 32% des répondants ont déclaré que leur organisation avait renoncé à acheter un ou plusieurs produits ou fonctionnalités logicielles précisément parce qu'elle pouvait construire la capacité en interne avec des outils de codage agentiques. C'est un changement structurel dans le calcul classique du build-vs-buy, porté par des outils qui n'existaient pas à grande échelle il y a un an.
L'appétit se concentre chez les gagnantes. Les quelque 6% de répondants que McKinsey classe comme les plus performantes — les organisations attribuant au moins 5% de leur EBIT à l'IA — sont les plus offensives, avec près de la moitié qui a évité un achat contre 31% de tous les autres. Par secteur, la technologie mène à 41%, suivie des assureurs et prestataires de santé à 39%, puis des services professionnels et de l'énergie à égalité à 38%. Les grandes entreprises s'y mettent aussi : 40% des sociétés de plus d'un milliard de dollars de revenus déploient désormais des agents IA à l'échelle dans une ou plusieurs fonctions, en forte hausse par rapport aux 27% de l'année précédente.
Un chiffre qui n'a pas bougé mérite qu'on le garde en tête. La part des organisations déclarant un impact sur le résultat net grâce à l'IA est restée stable à 37% d'une année sur l'autre. L'adoption s'accélère ; les rendements mesurés ne suivent pas encore. Cet écart est toute l'histoire derrière la question du build-vs-buy, et c'est pourquoi une décision de construire en interne exige la même rigueur que le recrutement d'une équipe d'ingénierie dédiée — car, fonctionnellement, c'est exactement ce qu'est la possession d'un logiciel.
Pourquoi le prix d'achat est le petit chiffre
Le prix d'achat d'un produit SaaS est visible, négocié et facile à pointer dans une revue budgétaire. C'est précisément pour cela qu'il est un ancrage trompeur. Lorsque vous refusez d'acheter et construisez à la place, vous n'éliminez pas le coût — vous convertissez une ligne d'abonnement prévisible en un coût d'exploitation ouvert que votre propre équipe porte désormais : maintenance, correctifs de sécurité, mises à jour de dépendances, disponibilité et astreinte, infrastructure, et le temps d'ingénierie continu pour maintenir la chose en vie tandis que les besoins et les plateformes se déplacent en dessous.
Le taux de base historique donne à réfléchir. La couverture des résultats McKinsey notait que les systèmes construits en interne n'ont réussi qu'environ un tiers du temps, contre environ deux tiers pour les solutions éditeurs — et Gartner prévoit que plus de 40% des projets d'IA agentique seront abandonnés d'ici fin 2027, largement à cause de coûts croissants et d'une valeur métier incertaine. Environ 20% des organisations ressentent déjà la pression des coûts d'exploitation de l'IA. Comme l'a formulé le senior partner McKinsey Lieven Van der Veken à propos du virage sous-jacent, les dirigeants demandent de plus en plus ce dont leurs organisations ont besoin pour construire elles-mêmes des outils d'IA — mais vouloir construire et pouvoir exploiter sont deux capacités différentes.
La leçon pratique est que le coût d'exploitation doit être une contrainte de conception dès le premier jour, pas une surprise en deuxième année. Un agent peut générer un prototype fonctionnel en une après-midi ; il ne peut pas, seul, rendre ce prototype observable, sécurisé, conforme et peu coûteux à faire tourner. Ce sont des décisions d'ingénierie, et c'est là que se décide le véritable coût total de possession.
Quand construire l'emporte sur acheter
Rien de tout cela ne plaide contre le fait de construire. Cela plaide pour construire délibérément. Les cas où un développement interne avec des agents IA de code l'emporte vraiment partagent quelques traits : la capacité est un véritable facteur de différenciation plutôt qu'une commodité ; les besoins sont suffisamment spécifiques à votre activité pour qu'aucun produit prêt à l'emploi ne convienne sans lourde personnalisation ; les données ou le flux de travail sont assez sensibles pour que les garder dans vos propres systèmes ait une valeur stratégique ; et vous avez — ou pouvez réunir — la discipline d'ingénierie pour assumer le résultat pendant des années, pas seulement livrer une démo.
Acheter l'emporte toujours pour la vaste surface des capacités de commodité : authentification, facturation, analytics, ticketing, CRM générique. Un éditeur mûr a déjà absorbé les cas limites, les certifications de conformité et la charge de maintenance, et aucune vélocité d'agent ne fait de leur reconstruction un bon usage du temps d'ingénierie senior. La stratégie la plus durable en 2026 n'est pas « tout construire maintenant que nous le pouvons » mais un portefeuille : acheter la commodité, construire le différenciateur, et être honnête sur ce qui relève de l'un ou de l'autre.
Ce que cela signifie pour les équipes en France et en UE
Pour les responsables d'ingénierie en France et en UE, les données McKinsey reformulent une décision familière plutôt qu'elles ne la tranchent. La première implication est que le build-vs-buy est désormais une question ouverte pour une part bien plus large de votre stack qu'il y a un an, parce que les outils agentiques ont effondré le coût de la première version fonctionnelle. C'est une véritable opportunité — et une véritable manière d'accumuler du logiciel interne non maintenu si les décisions se prennent par enthousiasme plutôt que par économie.
Ce que cela signifie pour le marché français : en France, l'élan du « build » rencontre une aspiration forte à la souveraineté numérique et à un « cloud de confiance », qui rend la construction interne d'autant plus attrayante pour garder données et savoir-faire chez soi. Mais construire, c'est aussi endosser la responsabilité : une équipe qui développe en interne devient elle-même responsable de traitement au sens du RGPD, sous le regard de la CNIL, et doit intégrer la conformité dès la conception (privacy by design). Pour les données sensibles ou les acteurs publics, viser une qualification de type SecNumCloud portée par l'ANSSI ne s'ajoute pas après le lancement : cela se décide dans l'architecture. Un prototype rapide qui saute la revue de sécurité et de confidentialité n'est pas une économie ; c'est une dette différée.
La deuxième implication est que la contrainte s'est déplacée. Quand un agent IA peut produire rapidement une implémentation plausible, la ressource rare n'est plus les gens qui savent écrire du code — c'est ceux qui savent le relire, le sécuriser et en assumer la responsabilité en production. Les équipes qui ont mis à l'échelle l'usage des agents sans mettre à l'échelle la relecture senior sont celles les plus susceptibles de figurer dans la statistique des projets abandonnés de Gartner. La troisième implication concerne les effectifs : les organisations qui tirent un réel impact EBIT de l'IA n'ont pas remplacé les ingénieurs par des agents ; elles ont placé des ingénieurs expérimentés à la tête des agents et traité le coût d'exploitation comme un objectif de conception de premier plan. C'est une compétence de product engineering — et précisément la lacune que la plupart des équipes internes sous-estiment lorsqu'elles décident de construire au lieu d'acheter.
Une checklist build-vs-buy pour 2026
- Nommez le différenciateur. Si la capacité n'est pas quelque chose que les clients remarqueraient ou paieraient, choisissez par défaut d'acheter. Réservez la construction à ce qui vous distingue réellement.
- Chiffrez l'exploitation, pas la construction. Estimez trois ans de maintenance, sécurité, infrastructure et astreinte avant de comparer à un abonnement. Le coût de construction est le petit chiffre.
- Vérifiez le taux de base. Partez du principe qu'un développement interne a plus de risques de caler qu'un déploiement éditeur, et demandez ce qui fait spécifiquement du vôtre l'exception.
- Recrutez pour la relecture, pas seulement la génération. Chaque composant généré par IA a besoin d'un ingénieur senior capable de le lire, le tester et l'assumer. Budgétez ce temps de relecture explicitement.
- Faites de la conformité un point de contrôle, pas une phase. Pour des données réglementées, la revue de sécurité et de confidentialité relève de la conception, pas de l'après-lancement. Une construction rapide qui échoue à un audit est plus lente qu'un achat.
- Fixez un critère d'arrêt. Décidez d'avance à quoi ressemble « ça ne marche pas » et quand vous basculeriez vers un éditeur. L'inertie des coûts irrécupérables est ce qui transforme une construction en projet abandonné.
- Réexaminez chaque année. Une capacité qui vaut la peine d'être construite aujourd'hui peut devenir l'an prochain une commodité qu'un éditeur résout mieux. Traitez le portefeuille comme quelque chose que l'on rééquilibre, pas que l'on fixe une fois pour toutes.
Questions fréquentes
Qu'a révélé l'enquête State of AI 2026 de McKinsey sur le build vs buy ?
Dans le rapport The State of AI in 2026 de McKinsey, publié le 25 août 2026, 32% des répondants ont déclaré que leur organisation avait renoncé à acheter au moins un produit ou une fonctionnalité logicielle parce qu'elle pouvait le construire en interne avec des outils de codage agentiques. L'enquête a recueilli 1 719 réponses dans 97 pays et s'est déroulée du 4 mai au 8 juin 2026. La tendance était la plus forte chez les plus performantes — les quelque 6% de répondants qui attribuent au moins 5% de leur EBIT à l'IA —, où près de la moitié a évité un achat contre 31% de leurs pairs.
Construire un logiciel en interne avec des agents IA fait-il vraiment économiser ?
Pas automatiquement. Le prix d'achat évité n'est que le coût d'acquisition. Un logiciel construit en interne porte le coût d'exploitation complet : maintenance, correctifs de sécurité, astreinte, infrastructure et le temps d'ingénierie pour le maintenir à jour. La couverture des données McKinsey notait que les systèmes construits en interne réussissent environ un tiers du temps contre environ deux tiers pour les solutions éditeurs, et Gartner prévoit que plus de 40% des projets d'IA agentique seront abandonnés d'ici fin 2027 pour cause de coûts et de valeur incertaine. Les agents IA réduisent le coût de la première version, pas le coût de possession.
Quels secteurs construisent le plus au lieu d'acheter ?
Selon la ventilation de l'enquête McKinsey, le secteur technologique arrive en tête avec 41% des répondants ayant renoncé à un achat, suivi des assureurs et prestataires de santé à 39%, puis des services professionnels et de l'énergie à 38%. Les grandes entreprises de plus d'un milliard de dollars de revenus déployaient aussi les agents à l'échelle, 40% les exécutant désormais dans une ou plusieurs fonctions, contre 27% l'année précédente.
Quand une équipe doit-elle construire avec des agents IA plutôt qu'acheter ?
Construisez lorsque la capacité est un véritable facteur de différenciation, que les besoins sont spécifiques à votre activité et que vous avez la discipline d'ingénierie pour en assumer le résultat sur le long terme. Achetez lorsque la capacité est une commodité, qu'un éditeur mûr la résout déjà et que le temps de votre équipe serait mieux employé ailleurs. Traitez le coût d'exploitation comme une contrainte de conception dès le premier jour plutôt qu'après coup, et affectez au projet des ingénieurs seniors capables de relire la production des agents — car le goulot d'étranglement est passé de l'écriture du code à sa relecture et à sa maintenance en toute sécurité.
Sources
McKinsey & Company — The State of AI in 2026: On the road to ROI (publié le 25 août 2026)
Forkast / Yahoo Finance — The Build-vs-Buy Shift: 32% of Enterprises Bet on Agentic Coding Tools (1er septembre 2026)