Build, Partner, Buy ou Defer : le framework McKinsey de l'agentic AI, lu côté achats

TL;DR : Le framework agentique de McKinsey est un Make-or-Buy appliqué à l'IA. Pour les CPO et les équipes digital/process : une vraie infrastructure IA va devenir complexe et coûteuse, les achats doivent être dans la pièce pour garder la facture sous contrôle, et "attendre" (Defer) est une décision légitime, souvent optimale. Ce n'est pas un plaidoyer contre l'achat d'IA. Le potentiel est réel quand c'est bien appliqué, alors expérimentez et emparez-vous du sujet.

"T'inquiète, on va vibecoder ça, ce sera facile." Si vous êtes CPO, ou dans une équipe digital ou process, vous avez entendu une version de cette phrase sur les agents IA. C'est rarement aussi facile, et rarement aussi bon marché.

Depuis 18 mois, chaque comité IT et digital reçoit la même demande : "on veut déployer des agents IA sur [finance, RH, support, sourcing, juridique]". Le métier arrive avec une POC, l'éditeur historique pousse son module agentique, une startup propose une solution dédiée, et la DSI hésite à tout réinternaliser. McKinsey a publié une architecture pour les plateformes agentiques en entreprise, accompagnée d'un arbre de décision Build / Partner / Buy / Defer. Il ne tranche pas à votre place, mais il pose les bonnes questions dans le bon ordre, ce qui manque précisément pour structurer un Make-or-Buy quand l'objet est une plateforme agentique, pas un logiciel SaaS classique.

1. L'architecture agentique (la version courte)

À lire si le sujet vous intéresse. C'est court volontairement, et vraiment utile, mais si vous ne voulez que la décision, sautez à la partie 2. Pour le tableau complet, l'article QuantumBlack est excellent : Creating a future-proof enterprise agentic platform architecture.

McKinsey décompose une plateforme agentique d'entreprise en quatre couches, du plus visible au plus profond, où beaucoup de choses devront être achetées. Les achats doivent être dans la boucle, parce que chacune de ces couches représente de l'argent réel et du risque réel. Commencez par l'infrastructure, c'est là que l'argent part le plus visiblement : compute, inférence, routage de modèles, passerelles. Puis remarquez que la gouvernance n'est pas une case en bout de chaîne : elle est là dès le départ, traverse toutes les couches, et devient la capacité à construire en premier.

• Marketplace & Workflows : la vitrine, agents pré-construits, workflows packagés, outils invocables. La couche que les éditeurs se disputent, et où commence le lock-in.
• Systèmes agentiques : la plomberie, en quatre archétypes (agents de productivité, highly custom, purpose-fit, workflow automation). Chacun implique un type de fournisseur et un modèle économique différents.
• Runtimes & Interfaces : runtimes plus passerelles API / MCP / LLM. Invisible, mais le premier poste de TCO. À traiter comme de l'infrastructure cloud, pas du SaaS.
• Services partagés & Cloud / Infrastructure : registries, observabilité, foundation models, et la ligne la plus sous-estimée de toutes, l'identité humaine et agentique. C'est elle qui décide si vous pourrez auditer ce que vos agents ont fait.

Une fois la pile complète sous les yeux, une chose saute aux yeux : l'essentiel n'est pas à vous de le construire, et la techno bouge encore vite. C'est exactement pour ça qu'attendre cesse d'être une dérobade et devient une décision normale et défendable.

2. Build vs Partner vs Buy vs Defer : la décision

C'est la moitié qui devrait atterrir sur le bureau de tout responsable en 2026. L'arbre de décision de McKinsey se lit du haut vers le bas. Je le reprends ci-dessous, avec à chaque fois la traduction en langage achats.

L'arbre de décision Build / Partner / Buy / Defer, d'après McKinsey QuantumBlack.

Question 1 : raison stratégique de construire la capacité ?

Si OUI, on passe à la question 2 (Partner ou Build). Si NON, on bascule vers la branche Buy / Defer.

Lecture achats : 80 % des cas d'usage agentiques en achats (catégorisation de spend, traitement de factures, génération de RFQ, analyse de contrats) ne sont pas différenciants. Le réflexe "on le code en interne avec Claude / GPT" coûte 3 à 5x plus cher sur 3 ans qu'une solution éditée, une fois le run, la maintenance et le retrofit modèle intégrés. Règle pratique : si ce n'est pas dans le top 3 des leviers compétitifs, la réponse est NON.

Question 2 : peut-on partenariser pour garantir nos exigences ?

Si OUI, c'est Partner. Si NON, c'est Build.

Lecture achats : c'est ici que se joue la négociation. Un vrai partenariat implique des SLA d'évolution (pas seulement de disponibilité), une clause d'exclusivité ou de co-développement, un droit de regard sur le fine-tuning avec vos données, et une clause de réversibilité sur les artefacts entraînés (poids, prompts, embeddings). Si le fournisseur refuse, le "partenariat" est un SaaS déguisé : traitez-le en Buy.

Question 3 : solution fit-for-purpose intégrable en gardant le contrôle ?

Si OUI, c'est Buy (en favorisant l'open-source). Si NON, on passe à la question 4.

Lecture achats : "l'influence sur la roadmap" est un critère rare dans les RFP, et c'est une erreur. Sur un agent qui orchestre un processus critique, l'absence d'influence sur la roadmap équivaut à une dépendance totale au calendrier de l'éditeur. À mettre en critère pondéré.

Question 4 : l'impact de différer est-il supérieur au TCO de Build / Partner ?

Si OUI, on remonte vers Partner ou Build. Si NON, c'est Defer.

Lecture achats : la question la plus contre-intuitive, et la plus puissante. Elle légitime de ne rien faire comme une décision active. Sur une techno qui se déprécie de 30 à 50 % par an, différer 6 à 12 mois est souvent le scénario à plus haut ROI. Documentez-le pour ne pas vous le faire reprocher plus tard.

Dans 100 % des comités agentiques que j'ai vus passer, personne n'a jamais proposé sérieusement "on attend 12 mois". C'est pourtant souvent le plus rentable.

Ce que ça veut vraiment dire pour les achats

Monter une vraie infrastructure IA va être compliqué et coûteux. Les achats doivent être là pour aider à construire cet écosystème, sinon les coûts partent hors de contrôle. Les factures IA qui explosent le montrent déjà, et on n'en est qu'au début. Pourtant le potentiel est grand quand la techno est bien appliquée, alors les entreprises, et les équipes achats, ont intérêt à expérimenter et à s'emparer du sujet plutôt qu'à le subir. Le rôle n'est pas de bloquer l'IA. C'est de s'assurer que quelqu'un dans la pièce demande ce que ça coûte, ce que ça verrouille, et si ce trimestre est le bon pour s'engager.

3. Comment l'opérationnaliser

3.1 Ajoutez l'arbre de décision au kit RFP

Avant toute consultation sur un cas d'usage agentique, demandez au métier de répondre aux quatre questions par écrit, avec justification. Vous obtenez une trace de la décision Make-or-Buy, un argumentaire à opposer aux éditeurs qui poussent en direct au métier, et un cadre de challenge pour la DSI quand elle pousse le Build.

3.2 Construisez une grille de pondération sur les cinq couches

Les RFP agentiques actuels surpondèrent la couche visible (UX, marketplace) et sous-pondèrent les couches profondes (runtimes, observabilité, identité). Une grille saine répartit les points sur les cinq couches de la partie 1 :

3.3 Imposez la question Defer dans chaque comité

La scénarisation doit toujours inclure un cas "on ne fait rien pendant 12 mois", avec coût d'opportunité chiffré. Ce n'est pas du sabotage, c'est de l'hygiène financière. Et dans 30 à 50 % des cas, c'est le scénario qui gagne.

Ce qu'il faut retenir

Le framework McKinsey n'invente rien : c'est un Make-or-Buy classique appliqué à un nouvel objet. Mais il a deux mérites. Il donne un cadre raisonnablement simple pour décider dans un environnement très incertain. Et il légitime le Defer comme une décision active, ce qui est probablement la posture la plus rentable face à une techno encore immature. Pour les achats, c'est l'occasion de reprendre la main sur des dossiers qui partent souvent directement entre la DSI et l'éditeur, en imposant un cadre de décision, une grille de pondération, et la question "et si on attendait ?" à chaque comité.

Rien de tout cela n'est un plaidoyer contre l'achat d'IA. Le potentiel est réel quand c'est bien appliqué. Alors expérimentez, emparez-vous du sujet, et veillez à ce que les achats soient dans la pièce pendant que vous le faites, parce que c'est comme ça que la facture reste saine et que l'écosystème se construit à dessein plutôt que par accident.

Vous voulez stress-tester votre prochain RFP agentique avant de le lancer ? Réservez 30 min ici.

Je suis Alex Lio. 10+ ans dans les achats indirects, dont 7 chez Amazon, aujourd'hui aux côtés de mes clients sur la digitalisation et l'IA.

Sources

1. McKinsey & Company, Rethinking enterprise architecture for the agentic era.
1. QuantumBlack, AI by McKinsey, Creating a future-proof enterprise agentic platform architecture (schéma d'architecture + arbre Build / Partner / Buy / Defer).
1. McKinsey & Company, Indirect procurement: Insource, outsource, or both.