Build vs Buy pour l’IA: choisir sans créer une dette stratégique

Décomposer le système avant de choisir

Build vs Buy est souvent présenté comme le choix entre une équipe interne et une licence. Une application IA est pourtant un système composé: modèle, base documentaire, pipeline de données, orchestration, règles, identité, interface, évaluation, logs et exploitation. Ces éléments n’ont ni la même maturité de marché ni la même valeur stratégique.

Dessinez les composants et classez chacun selon différenciation, sensibilité, fréquence de changement et disponibilité d’une solution standard. Cette carte révèle généralement une architecture hybride: certaines briques sont achetées, d’autres intégrées et quelques-unes construites autour du métier.

Comparer le TCO des trois options

Le développement interne concentre les coûts au départ puis exige maintenance, recrutement, infrastructure et veille. Le SaaS réduit le délai initial, mais ajoute licences, intégration, gouvernance, dépendance et parfois un prix variable avec le volume. L’approche hybride demande une architecture plus disciplinée mais permet de placer le contrôle sur les couches importantes.

Projetez le coût sur plusieurs horizons de volume. Ajoutez le coût du changement de fournisseur, des hausses tarifaires et des évolutions de modèle. Une option bon marché pendant le pilote peut devenir coûteuse lorsque le volume, la rétention des données ou les contrôles augmentent.

Choisir entre prompt, API, RAG et fine-tuning

Ces options ne se situent pas toutes au même niveau. Une API est un mode d’accès à une capacité. Le prompt définit la tâche et le contexte immédiat. Le RAG récupère des informations externes au moment de la requête. Le fine-tuning adapte le comportement d’un modèle à partir d’exemples. Une solution peut donc utiliser une API, un prompt structuré et un RAG en même temps.

La bonne séquence commence par le mécanisme le plus simple qui atteint le seuil de qualité. Ajoutez du RAG lorsque la réponse doit s’appuyer sur des documents privés ou fréquemment mis à jour. Envisagez le fine-tuning lorsque le problème porte sur un comportement spécialisé et répétable, avec assez d’exemples de qualité et une évaluation qui démontre un gain réel.

Faire la due diligence du SaaS et des modèles

Un essai fonctionnel ne remplace pas la due diligence. Testez les cas difficiles, le comportement en limite, les langues réelles, la continuité et les modalités de suppression. Vérifiez aussi qui assume la responsabilité lorsque la solution est intégrée à une décision ou à un processus client.

• Données utilisées pour l’entraînement, rétention, localisation et sous-traitants.
• SLA, limites de débit, versionnement, dépréciation et changement silencieux du modèle.
• Export des données, logs, prompts, évaluations et configurations.
• Contrôles d’accès, chiffrement, journalisation, incidents et audit indépendant.
• Conditions de sortie, assistance à la migration et coût contractuel de réversibilité.

Construire une couche de portabilité réaliste

L’abstraction totale entre fournisseurs peut coûter plus cher qu’elle ne protège. Isolez plutôt les dépendances fortes: format des messages, accès aux modèles, stockage des prompts, évaluations, observabilité et règles métier. Conservez des jeux de tests indépendants pour comparer une option de remplacement.

La portabilité doit être prouvée. Exécutez un petit test de remplacement pendant le pilote et mesurez les écarts de qualité, coût et latence. Documentez les fonctions propres au fournisseur que l’entreprise accepte volontairement en échange d’un avantage.

Prendre une décision révisable

Le choix doit préciser la durée de validité des hypothèses, les déclencheurs de revue et les options conservées. Les prix, modèles et capacités changent rapidement. Une décision pertinente aujourd’hui peut devoir être réévaluée après une hausse de volume, une exigence réglementaire ou une amélioration du marché.

GOV.UK recommande de passer par une phase de découverte et de tester plusieurs options avant de s’engager sur une solution commerciale. Cette discipline est particulièrement importante pour l’IA, où une démonstration rapide peut cacher la charge d’intégration et d’exploitation.