Build vs Buy. Quand développer son agent IA, quand licencier une plateforme.

Pourquoi « build vs buy » est un faux binaire.

La conversation build vs buy arrive généralement sous une forme polarisée. Un camp défend l'achat d'une plateforme parce que le marché bouge vite et que les constructions internes sont lentes. L'autre défend la construction parce que les fournisseurs facturent au prix fort des capacités que l'équipe pourrait assembler en un trimestre. Les deux contiennent une part de vérité et passent tous deux à côté du point structurel.

Chaque système IA en production que nous avons aidé à construire, supervisé ou audité a été un mélange. Le modèle lui-même était loué à un fournisseur frontière. Le framework d'orchestration était de l'open source avec des extensions. Le vector store était un service managé. La suite d'évaluation, la piste d'audit et la bibliothèque de prompts étaient construites en interne parce qu'elles encodaient une connaissance spécifique au client. La question que nous posons aux équipes dirigeantes n'est pas de savoir s'il faut construire ou acheter. C'est de savoir quelles couches appartiennent à quelle colonne, et ce que coûte de se tromper sur cette répartition.

D'après notre expérience, le débat build vs buy est presque toujours un proxy pour une autre question. Qui contrôle le rythme de changement. Qui possède la différenciation. Qui porte le risque quand la technologie sous-jacente se déplace sous le système. Ce sont ces conversations qui valent la peine, et le cadre ci-dessous tend à les faire avancer.

Ce que vous devez posséder.

L'ontologie métier.

Par ontologie métier, nous entendons la représentation formelle des entités, des relations et des règles qui définissent votre activité. Ce qu'est un client, ce qu'est une transaction, à quoi ressemble une exception. Ce n'est pas quelque chose qu'un fournisseur peut vous vendre sous une forme générique. La posséder est ce qui permet à toute capacité IA que vous déployez d'être ancrée dans votre réalité plutôt que dans une réalité généralisée. Les équipes qui le font bien passent généralement les premières semaines de tout projet IA sur l'ontologie avant de toucher à un modèle. Celles qui sautent cette étape découvrent que chaque sortie demande un nettoyage substantiel.

Le pipeline d'évaluation.

L'ensemble des cas de test qui définit ce qu'est un bon résultat pour vos agents est une propriété intellectuelle de cœur. Il encode la connaissance des opérateurs, les cas limites, les attentes réglementaires et le ton de voix sous une forme que l'équipe peut exécuter à chaque changement. Louer un framework d'évaluation est raisonnable. Louer les cas eux-mêmes n'a aucun sens. Nous voyons des clients confondre les deux assez souvent pour que ce soit l'un des premiers points que nous examinons en audit.

La piste d'audit.

L'enregistrement de ce que le système a fait, pourquoi, et sous quelle autorité est quelque chose que vous ne pouvez pas vous permettre de laisser stocké uniquement dans la base d'un fournisseur sous sa politique de rétention. Possédez la piste. Recopiez-la dans une infrastructure que vous contrôlez. Les raisons réglementaires et opérationnelles sont bien rodées et le coût de bien le faire est modeste. Le coût de découvrir que vous ne pouvez pas répondre à un régulateur à temps parce que le calendrier d'export du fournisseur est mensuel est significatif.

La bibliothèque de prompts et de politiques.

Les prompts qui définissent la manière dont vos agents raisonnent, les politiques qui gouvernent ce qu'ils peuvent faire et le ton qu'ils appliquent constituent une différenciation. C'est aussi l'endroit où se passe l'itération la plus valorisée pendant la première année d'exploitation. Les garder dans un format propre à un fournisseur qui ne peut pas être migré semble correct jusqu'au jour où vous voulez bouger, moment où le coût de migration peut effacer le gain de vitesse qui avait motivé l'achat initial.

Ce que vous devez louer.

L'accès au modèle.

Le modèle frontière lui-même est l'exemple le plus clair d'une couche à louer. Le rythme d'amélioration des foundation models dépasse de loin ce que toute équipe interne peut suivre, et l'économie de l'entraînement d'un modèle compétitif ne fonctionne pour quasiment aucune entreprise que nous ayons conseillée. Utilisez le meilleur modèle que le marché propose, concevez pour la commutation, et mettez à jour la suite d'évaluation pour détecter les régressions quand vous changez de fournisseur.

La plomberie d'orchestration.

Les frameworks qui câblent ensemble modèles, outils, recherche et mémoire sont assez matures pour qu'en construire un soi-même soit rarement défendable. Les options open source sont crédibles, les options commerciales sont bien supportées, et le capital d'ingénierie épargné en louant cette couche est mieux dépensé sur la suite d'évaluation et la piste d'audit. Les équipes avec qui nous travaillons qui ont construit leur propre orchestration le regrettent généralement en un an, à mesure que l'écosystème open source les rattrape et les dépasse.

L'outillage d'observabilité.

Le tracing, la surveillance de latence, le suivi de coût et la détection de dérive pour les systèmes IA forment une catégorie qui bouge vite avec des fournisseurs spécialisés crédibles. Le construire en interne est coûteux et produit généralement un outil en retard sur le marché. Louez-le, intégrez-le profondément, et possédez les tableaux de bord qui font remonter les signaux à vos opérateurs.

Stockage et recherche vectoriels.

Les bases de données vectorielles managées et les services de recherche ont assez mûri pour que la justification opérationnelle de l'auto-hébergement soit étroite. Quand elle subsiste, c'est généralement pour des raisons réglementaires ou de souveraineté plutôt que de performance. Pour la plupart de nos clients, louer cette couche est le bon choix, sous réserve que l'index puisse être exporté et reconstruit chez un autre fournisseur sans perdre le corpus sous-jacent.

La matrice de décision.

Quand la conversation doit être tranchée rapidement, la matrice que nous utilisons note chaque capacité sur deux axes. La criticité, c'est-à-dire la mesure dans laquelle votre modèle opératoire dépend du bon fonctionnement précis de cette capacité. La différenciation, c'est-à-dire la mesure dans laquelle posséder cette capacité vous sépare de concurrents qui pourraient autrement acheter les mêmes sorties chez les mêmes fournisseurs.

Haute criticité et haute différenciation placent la capacité dans la colonne build. L'ontologie métier et la suite d'évaluation y atterrissent généralement. Faible criticité et faible différenciation la placent fermement dans la colonne rent. Le stockage vectoriel et l'outillage d'observabilité y atterrissent généralement. Les cas intéressants sont sur la diagonale : haute criticité et faible différenciation, ou faible criticité et haute différenciation. Ce sont les cas où la plupart des désaccords se produisent et où la plupart des erreurs d'achat sont commises. La matrice oblige la salle à choisir explicitement plutôt qu'à dériver.

Acheter de la vitesse sans perdre sa marge de manœuvre.

La raison la plus forte d'acheter est la vitesse. Une plateforme qui vous emmène de zéro à une capacité fonctionnelle en quelques semaines a une vraie valeur, et nous n'avons rien à reprocher aux clients qui choisissent d'acheter agressivement pour entrer en production. La conversation que nous insistons pour mener porte sur ce qui se passe au mois dix-huit. Les prompts peuvent-ils être exportés. Les cas d'évaluation peuvent-ils être migrés. La piste d'audit peut-elle être conservée à la fin du contrat. Le fournisseur de modèle peut-il être changé sans reconstruction complète.

Si la réponse à ces quatre questions est oui, acheter est une stratégie saine. Si la réponse à l'une d'elles est non, l'acheteur prend un risque d'une nature différente de celui qu'il réalise probablement. La remise consentie par le fournisseur pour emporter l'affaire est généralement une petite fraction du coût de migration que le client paiera plus tard. Nous avons accompagné des clients dans ce calcul plus d'une fois et la conclusion a été constante.

Si votre équipe approche d'une décision build vs buy et que la conversation se polarise, la question utile à ouvrir n'est pas quel camp a raison. C'est lesquelles, exactement, des capacités, sont de quel côté de la ligne, et quelle marge de manœuvre vous achetez ou vendez dans chaque direction. Les équipes Tech Factory et Consulting de nos bureaux de Paris, Dubaï, Singapour et Bali sont joignables depuis le formulaire ci-dessous.