Build vs buy IA : acheter, intégrer ou développer ?

Un choix build vs buy IA n’oppose pas simplement un logiciel acheté à un modèle développé en interne. Quatre voies existent le plus souvent : utiliser un SaaS prêt à l’emploi, intégrer une API dans un processus, héberger une solution configurable sous davantage de contrôle, ou construire un système spécifique. La bonne décision dépend moins du prestige technique que de cinq contraintes : le travail à accomplir, les données autorisées, le niveau de contrôle requis, la capacité d’exploitation et le coût de sortie.

Commencez par éliminer les options incompatibles avec vos contraintes. Comparez ensuite les options restantes sur le même scénario et avec les mêmes preuves. Enfin, choisissez une solution réversible pour un périmètre borné. Une matrice très détaillée ne compense jamais un besoin mal défini, un fournisseur impossible à auditer ou une équipe incapable d’exploiter le système après le pilote.

Réponse en bref

Pour trancher un build vs buy IA :

1. décrivez la décision ou la production attendue sans présumer de la solution ;
2. distinguez SaaS, API intégrée, solution hébergée et développement spécifique ;
3. éliminez les options incompatibles avec les données, la sécurité, le droit ou la continuité ;
4. testez chaque option survivante sur un jeu de cas identique ;
5. comparez qualité, délai d’intégration, contrôle, exploitation, adoption et coût complet ;
6. chiffrez le coût de changement ou de sortie, pas seulement le coût d’entrée ;
7. documentez ce qui reste à la charge de votre organisation ;
8. choisissez une première étape réversible assortie d’un seuil d’arrêt.

La prochaine action utile est de remplir une fiche d’une page pour un seul processus. Elle doit nommer les utilisateurs, les entrées, la sortie utile, les erreurs graves, les données manipulées et le volume attendu. Sans ce contrat de besoin, le débat « acheter ou développer » devient une comparaison de démonstrations commerciales.

Les quatre options que cache le build vs buy

Le vocabulaire binaire masque des architectures très différentes. Les séparer évite de comparer un abonnement utilisable demain à un chantier logiciel de plusieurs mois.

Le SaaS prêt à l’emploi

Le fournisseur livre l’interface, les modèles, les mises à jour et une grande partie de l’exploitation. Cette voie convient lorsque le besoin est standard, que les utilisateurs peuvent travailler dans l’outil et que les garanties contractuelles correspondent aux données traitées.

L’organisation garde pourtant des responsabilités : configuration des accès, consignes d’usage, contrôle des données envoyées, vérification des résultats, gestion des départs et suivi du fournisseur. « Prêt à l’emploi » ne signifie pas « sans intégration organisationnelle ».

L’API intégrée

Une API permet d’insérer une capacité de modèle dans une application ou un workflow existant. L’expérience utilisateur, les règles métier, les validations et les journaux restent davantage maîtrisés. Le fournisseur conserve toutefois la maîtrise de son service, de ses modèles disponibles, de ses limites et de ses évolutions.

Cette option réduit le temps nécessaire pour entraîner et servir un modèle. Elle crée en échange un travail logiciel réel : authentification, gestion des erreurs, observabilité, évaluation, maîtrise des coûts et plan de migration. Le sujet n’est donc pas seulement le tarif par appel.

La solution hébergée sous contrôle

Un modèle ou un produit configurable peut être exploité dans une infrastructure choisie par l’organisation ou par un prestataire. Cette voie augmente parfois la maîtrise de la localisation, de la configuration et du cycle de vie. Elle ne supprime pas les dépendances : composants libres, poids de modèles, images de conteneurs, bibliothèques, matériel et prestataires forment une chaîne à maintenir.

Elle est pertinente lorsque les contraintes de données ou de continuité justifient cette charge et que l’équipe sait surveiller, mettre à jour et sécuriser l’ensemble. Héberger un modèle n’apporte pas automatiquement une meilleure qualité ni une conformité automatique.

Le développement spécifique

Construire signifie assembler une expérience, des règles, des données, des évaluations et une exploitation propres. Cela ne veut presque jamais dire entraîner un grand modèle depuis zéro. Le système peut encore dépendre d’API, de modèles ouverts ou de services managés.

Cette voie se justifie lorsque le processus constitue un avantage distinctif, que les règles ne rentrent pas dans un produit standard, ou qu’un niveau précis de contrôle et d’intégration crée une valeur durable. Elle devient fragile si elle sert seulement à reproduire une fonction banale déjà disponible et maintenue ailleurs.

Écrire le contrat du besoin avant de consulter le marché

Une décision solide commence par le travail, pas par la liste des outils. Décrivez une unité observable : « préparer une proposition de réponse et ses preuves pour validation » est plus utile que « déployer un assistant ».

La fiche minimale contient :

• l’événement qui déclenche le travail ;
• le rôle qui fournit l’entrée et celui qui utilise la sortie ;
• les systèmes et données nécessaires ;
• la sortie considérée comme acceptée ;
• les erreurs tolérables et les erreurs graves ;
• la référence actuelle de délai, de coût et de qualité ;
• le volume médian et les pointes ;
• le contrôle humain attendu ;
• la procédure de repli si l’IA ou le fournisseur est indisponible.

Ce travail complète la priorisation d’un portefeuille de cas d’usage IA. Le portefeuille répond à « quel problème tester d’abord ? ». Le build vs buy répond ensuite à « quel mode de sourcing convient à ce problème ? ». Mélanger les deux conduit souvent à choisir une solution séduisante avant d’avoir choisi un cas utile.

La CNIL et France Num recommandent notamment de considérer le besoin, la gestion des données, la fiabilité du fournisseur, l’accompagnement des utilisateurs et le coût global. Ces dimensions doivent apparaître dans la fiche avant toute notation. Sinon, une option peut gagner grâce à une fonction secondaire tout en échouant sur une contrainte essentielle.

Appliquer six filtres éliminatoires

Un score moyen ne doit pas rendre acceptable une option interdite, impossible à sécuriser ou inexploitable. Commencez par six questions binaires. Une réponse négative place l’option en attente tant que le défaut n’est pas corrigé.

1. Les données peuvent-elles suivre ce trajet ?

Cartographiez les catégories de données, les lieux de traitement, les sous-traitants, la conservation, les usages secondaires et les mécanismes de suppression. Pour un service hébergé, examinez le contrat et les paramètres réellement applicables à l’offre choisie. Pour une solution maîtrisée, examinez aussi les journaux, les sauvegardes et l’accès des équipes d’exploitation.

La CNIL souligne qu’un déploiement sur site peut être plus approprié pour certaines données personnelles ou sensibles, tandis qu’un service hébergé peut simplifier le démarrage mais exige une vigilance contractuelle et technique. Il n’existe pas de réponse universelle : le flux concret de données tranche.

2. L’option peut-elle satisfaire les exigences de sécurité ?

Listez les contrôles requis : identité, moindre privilège, séparation des environnements, chiffrement, filtrage des entrées, résistance à l’injection, supervision et réponse aux incidents. Demandez des preuves vérifiables, pas une simple affirmation de « sécurité entreprise ».

Les recommandations de l’ANSSI permettent de transformer cette question en mesures techniques et organisationnelles. Elles s’appliquent aussi au développement interne : posséder le code ne garantit ni le durcissement de l’infrastructure ni la qualité de la chaîne de dépendances.

3. Une personne ou une équipe est-elle responsable du service ?

Le propriétaire doit pouvoir arrêter le système, arbitrer une évolution, traiter une alerte et décider de la qualité acceptable. Si personne ne possède le service après le pilote, acheter reporte le problème et construire l’amplifie.

Précisez également les responsabilités du fournisseur. Qui restaure les données ? Qui annonce une modification de modèle ? Qui qualifie un incident ? Qui conserve les traces nécessaires ? Une zone grise doit être résolue avant le choix.

4. La sortie peut-elle être évaluée avant et après lancement ?

Préparez un jeu représentatif contenant des cas ordinaires, rares et sensibles. Définissez une grille et un arbitre. Une solution impossible à tester avec vos cas réels ne peut pas être comparée honnêtement.

Le fournisseur peut apporter des évaluations générales, mais elles ne remplacent pas votre seuil métier. Une réponse élégante peut omettre une preuve obligatoire. Un modèle moins impressionnant peut être préférable s’il respecte mieux une structure et un contrôle.

5. Le service possède-t-il un mode dégradé ?

Le processus doit continuer, ralentir proprement ou s’arrêter sans créer de dommage. Vérifiez l’export, la reprise manuelle, les files en attente et les limites de débit. Pour une fonction critique, une dépendance sans plan de continuité élimine l’option, même si son prix est attractif.

6. Le rôle juridique et contractuel est-il compris ?

Identifiez les parties, leurs obligations, les licences, les restrictions d’usage, les garanties et la procédure de fin de contrat. Le choix technique ne suffit pas à déterminer le rôle de chacun. Une solution ouverte, modifiée ou intégrée peut déplacer les responsabilités selon le contexte. Ce point demande une analyse adaptée, pas une conclusion copiée d’un tableau générique.

Comparer les options survivantes sur huit axes

Après les filtres, utilisez une échelle courte, par exemple de 1 à 4, et joignez une preuve à chaque note. Une note sans source devient une opinion.

Axe	Question de décision	Preuve attendue
Adéquation	La solution produit-elle le résultat attendu sur nos cas ?	Test aveugle et taux d’acceptation
Délai	Quand le premier périmètre utile peut-il fonctionner ?	Plan avec dépendances et responsables
Contrôle	Pouvons-nous régler, observer et arrêter le système ?	Démonstration des contrôles et journaux
Intégration	Le système s’insère-t-il dans le travail existant ?	Prototype sur un flux représentatif
Exploitation	Avons-nous la capacité de maintenir le service ?	Charge, astreinte, mises à jour et compétences
Adoption	Les personnes concernées peuvent-elles l’utiliser correctement ?	Test utilisateur et plan d’accompagnement
Économie	Quel est le coût complet par résultat accepté ?	Scénarios bas, central et haut
Réversibilité	Que faut-il pour changer ou arrêter ?	Test d’export, inventaire des dépendances et délai

Ne mélangez pas automatiquement ces axes dans une moyenne. Une organisation peut décider que contrôle et réversibilité doivent atteindre au moins 3 sur 4, puis comparer les options admissibles sur le reste. Les seuils rendent la gouvernance plus lisible que des pondérations ajustées après coup pour faire gagner l’option préférée.

Pour le coût, réutilisez une unité métier et le calcul du coût d’un agent IA par tâche acceptée. Incluez licence, consommation, intégration, sécurité, évaluation, formation, support, supervision et temps de contrôle. Séparez le coût initial du coût récurrent afin de ne pas pénaliser artificiellement une option ni de masquer sa maintenance.

Chiffrer le coût de sortie

La réversibilité reste souvent la colonne vide du tableur. Pourtant, une solution peu chère à adopter peut devenir coûteuse à quitter. Le coût de sortie comprend au moins :

• l’export et la remise en forme des données ;
• la réécriture des connecteurs et des règles propriétaires ;
• la reconstruction des évaluations et des jeux de référence ;
• la migration des identités, journaux et contrôles ;
• la formation des utilisateurs à la solution suivante ;
• la période de double exploitation ;
• le risque de perte de fonctions ou de qualité ;
• le délai contractuel et la suppression vérifiable des données.

Demandez un export pendant l’évaluation, pas le jour de la résiliation. Vérifiez son format, sa complétude et le temps de récupération. Pour une API, isolez les appels derrière une interface interne et conservez vos jeux d’évaluation. Pour une solution hébergée, inventoriez versions, dépendances, configurations et licences. Pour un développement spécifique, documentez ce qu’une autre équipe devrait reprendre.

La réversibilité ne signifie pas qu’un changement sera gratuit. Elle signifie que le chemin est connu, testé à petite échelle et compatible avec le risque accepté. Une migration de modèle IA sans régression devient beaucoup plus simple lorsque ce travail a été prévu avant la première intégration.

Organiser un duel de preuves, pas de présentations

Réduisez la comparaison à deux ou trois options réellement admissibles. Donnez-leur le même paquet d’essai : même description du besoin, mêmes cas, mêmes critères et même délai. Les fournisseurs peuvent proposer une configuration optimale, mais chaque différence doit être documentée.

Le protocole peut tenir en cinq étapes :

1. constituer trente à cent cas anonymisés ou synthétiques mais représentatifs ;
2. définir avant le test les critères d’acceptation et les erreurs graves ;
3. faire exécuter les cas sans dévoiler aux évaluateurs l’option utilisée quand cela est possible ;
4. mesurer qualité, latence, coût, interventions et échecs ;
5. rejouer quelques cas après une modification de configuration pour observer la stabilité.

Ajoutez un exercice d’exploitation : révoquer un accès, retrouver une trace, traiter une indisponibilité, exporter les données et mettre à jour un composant. Une démonstration centrée sur le meilleur parcours ne révèle ni les responsabilités ni la charge quotidienne.

Si un prestataire accompagne la décision, un cahier des charges de consultant IA peut cadrer livrables, preuves et transfert. Le consultant ne doit pas être rémunéré uniquement pour installer l’option qu’il recommande sans rendre explicites ses intérêts et les alternatives examinées.

Lire quatre profils de décision

La matrice ne produit pas une réponse identique pour toutes les organisations. Elle aide à reconnaître un profil dominant.

Acheter un SaaS

Cette décision est cohérente lorsque le processus est standard, le temps de mise en service déterminant, les intégrations limitées et les garanties suffisantes. Le pilote doit surtout vérifier l’usage réel, l’administration, le contrat et la récupération des données.

Intégrer une API

Cette voie convient lorsqu’une application ou un workflow existe déjà, que l’organisation veut maîtriser l’expérience et les validations, mais ne veut pas exploiter elle-même le modèle. Les capacités d’ingénierie, d’observabilité et de gestion des versions deviennent alors décisives.

Héberger une solution configurable

Cette option devient plausible lorsque le contrôle des données, des versions ou de l’infrastructure justifie l’effort. Elle demande des compétences d’exploitation et un budget réaliste pour les mises à jour, les évaluations et la sécurité.

Construire un système spécifique

Le développement se défend lorsque la logique de travail est différenciante, que l’intégration produit une valeur difficile à obtenir autrement et que l’organisation peut maintenir le service. Il doit rester modulaire : interfaces remplaçables, données exportables, évaluations conservées et décision d’arrêt possible.

Un résultat hybride est fréquent. Une organisation peut acheter l’interface de collaboration, intégrer une API pour un traitement spécialisé et conserver ses règles et évaluations dans son propre système. Le but n’est pas la pureté d’une catégorie, mais une répartition explicite du contrôle et de la charge.

Produire un dossier de décision réversible

Le dossier final doit permettre à une personne absente du projet de comprendre le choix. Il contient :

• le contrat du besoin et la situation de référence ;
• les options considérées et celles éliminées, avec la raison ;
• les résultats du test commun ;
• la carte des données et des responsabilités ;
• les coûts initiaux, récurrents et de sortie ;
• les hypothèses encore non vérifiées ;
• le périmètre du premier déploiement ;
• les seuils de poursuite, de correction et d’arrêt ;
• la date de réexamen du choix.

La décision peut alors prendre une forme précise : « intégrer l’API A pendant huit semaines pour ce flux, sous ce plafond de coût et ce seuil de qualité, avec reprise manuelle et export testé ; réexaminer l’hébergement si le volume ou les données changent ». Cette formulation est plus utile que « nous avons choisi d’acheter », car elle relie le choix à des conditions observables.

Une décision réversible ne cherche pas à prédire tout le marché. Elle limite l’exposition tout en produisant les preuves nécessaires à l’étape suivante. C’est souvent la meilleure réponse à un environnement où les modèles, les tarifs et les offres évoluent plus vite que les processus d’achat.

Limites

Cette méthode ne remplace ni une analyse juridique, ni un audit de sécurité, ni une procédure d’achat adaptée à votre organisation. Les obligations applicables dépendent du rôle des acteurs, des données, du secteur, du pays et de l’usage concret. Les offres, licences, modèles, prix et modalités d’hébergement peuvent évoluer après la date de vérification indiquée.

Une matrice ne garantit pas non plus le succès d’adoption. Elle réduit les angles morts au moment du choix, mais la qualité réelle doit être suivie après lancement. Pour un usage critique, sensible ou difficilement réversible, faites examiner le dossier par les fonctions compétentes et conservez un mode de repli indépendant du système d’IA.

Articles liés

• Prioriser les cas d’usage IA : construire un portefeuille pilotable
• Coût d’un agent IA : calculer le coût par tâche avant un pilote
• Migration de modèle IA : changer sans régression
• Consultant IA : cadrer et déployer des projets utiles