Évaluer les fournisseurs d'IA et arbitrer entre build et buy

L'associé en charge de l'innovation dans un cabinet d'avocats de taille moyenne examine deux propositions. La première : un contrat à 150 000 $ par an avec un éditeur d'IA juridique qui promet l'automatisation de la revue de contrats. La seconde : une estimation approximative du responsable IT du cabinet, trois mois et environ 40 000 $ pour construire un outil interne léger à partir d'APIAPIApplication Programming Interface : une interface standardisée qui permet aux applications de communiquer et d'échanger des données sans connaître leur fonctionnement interne respectif.Voir la définition complète → de grands modèles de langage (LLMLLMUn Large Language Model est un système d'IA entraîné sur d'énormes volumes de texte pour prédire et générer du langage, ce qui permet de rédiger, résumer ou répondre à des questions.Voir la définition complète →) disponibles sur étagère. Même problème, chemins radicalement différents. C'est le point de décision que rencontre tout cabinet de services professionnels dès que l'IA passe du statut de « démo intéressante » à celui de ligne budgétaire.

Pourquoi cette décision est plus difficile qu'il n'y paraît

Les cabinets de services professionnels (droit, comptabilité, conseil, advisory) vendent du jugement, pas seulement du logiciel. Cela modifie un calcul que les fournisseurs ne mettent pas toujours en avant :

• Les obligations de confidentialité client (secret professionnel de l'avocat, règles d'indépendance de l'auditeur) limitent les endroits où les données peuvent circuler.
• La précision métier compte davantage que la fluidité générale. Un outil qui résume bien les contrats mais rate une clause de responsabilité propre à une juridiction crcrLe pourcentage de visiteurs ou de prospects qui réalisent une action attendue (achat, inscription, formulaire de contact), calculé en divisant les conversions par le nombre total d'opportunités.Voir la définition complète →ée un vrai risque professionnel.
• Les systèmes existants (logiciels de practice management comme Clio ou iManage, ou plateformes d'audit) contiennent déjà les données du cabinet. Un nouvel outil qui ne dialogue pas avec eux génère du travail en double, ce qui tue l'adoption.

La question build ou buy en cache en réalité trois : est-ce une capacité que nous devons contrôler, pouvons-nous la construire de manière crédible, et la réponse du fournisseur à ces deux premiers points tient-elle vraiment à l'examen.

La grille d'évaluation

Utilisez une grille pondérée simple pour comparer une proposition fournisseur à un build interne. Notez chaque dimension de 1 à 5, pondérez selon son importance pour votre pratique, et faites le total. La grille impose la même rigueur aux deux options, car les projets internes échappent souvent à l'examen réservé aux fournisseurs.

1. Sécurité des données et confidentialité

• Où vont les données ? Sont-elles traitées par un fournisseur de modèle tiers, et sous quelles conditions contractuelles ?
• Existe-t-il un data processing agreement (DPA) et, pour les clients européens, une conformité au RGPDRGPDRèglement de l'UE encadrant la collecte, le stockage et l'usage des données personnelles, avec des amendes indexées sur le chiffre d'affaires mondial.Voir la définition complète → (Règlement général sur la protection des données) ?
• Le fournisseur entraîne-t-il ses modèles sur vos données par défaut ? (Beaucoup de contrats entreprise l'excluent désormais, mais vérifiez la clause réelle, pas la page marketing.)
• Pour un build : qui contrôle les accès au sein du cabinet, et existe-t-il une piste d'audit ?

2. Précision sur les tâches métier

• Demandez des résultats de benchmark sur des tâches qui ressemblent aux vôtres, pas des scores de leaderboard génériques. La performance d'un outil de revue de contrats sur des NDA ne vous dit pas grand-chose de sa performance sur une due diligence M&A transfrontalière.
• Exigez un pilote avec vos propres documents caviardés, pas les données de démo du fournisseur.
• Vérifiez les taux d'hallucinationhallucinationUne hallucination, c'est lorsqu'un modèle d'IA produit une réponse fluide et assurée mais factuellement fausse, inventée, ou non étayée par ses données sources.Voir la définition complète → sur les tâches à forte densité de citations. Les outils de recherche juridique ont connu des échecs bien documentés sur ce point, y compris des écritures sanctionnées par des tribunaux citant des affaires fabriquées (un problème largement rapporté depuis 2023).
• Pour un build : quel modèle appelez-vous, et quelqu'un l'a-t-il validé sur vos types de documents ?

3. Intégration avec les systèmes de practice management

• L'outil dispose-t-il d'une application programming interface (API, un moyen défini pour que des systèmes logiciels échangent des données) documentée qui se connecte à votre système existant de gestion des dossiers, de facturation ou de gestion documentaire ?
• Exigera-t-il des exports/imports manuels, que les équipes abandonneront discrètement en quelques semaines ?
• Pour un build : l'intégration est en général le coût le plus sous-estimé. Un outil interne « simple » qui ne peut pas récupérer automatiquement les données des dossiers finit au placard.

4. Viabilité du fournisseur et lock-in

• Depuis combien de temps le fournisseur opère-t-il, et qui sont ses clients de référence dans votre domaine de pratique ?
• Qu'advient-il de vos données et de vos workflows si le fournisseur est racheté ou cesse son activité ? (La legal tech a connu une vraie consolidation, par exemple l'acquisition de Casetext par Thomson Reuters en 2023.)
• Pour un build : que se passe-t-il si l'unique ingénieur qui l'a construit s'en va ?

5. Coût total de possession

• Fournisseur : abonnement plus implémentation plus formation plus temps d'administration interne.
• Build : développement plus coûts continus d'API du modèle plus maintenance plus coût d'opportunité du temps IT.

Une comparaison chiffrée

Reprenons l'exemple de la revue de contrats. Estimations approximatives, clairement identifiées comme telles :

Option fournisseur : 150 000 $/an, support d'implémentation inclus, précision mesurée (selon les affirmations du fournisseur) à environ 85 à 90 % de concordance avec la revue d'un collaborateur senior sur des contrats commerciaux standards (estimation communiquée par le fournisseur, à vérifier systématiquement de façon indépendante).

Option build : 40 000 $ de construction en one-shot à partir d'une API de LLM généraliste (estimation du coût du temps de développeur et de l'usage de l'API, tarifs 2025 à 2026), plus un montant estimé de 15 000 à 25 000 $/an de coûts d'API et de maintenance récurrents. Précision inconnue tant qu'elle n'est pas testée, probablement plus faible au départ sans fine-tuningfine-tuningLe fine-tuning adapte un modèle pré-entraîné à une tâche ou un domaine précis en poursuivant son entraînement sur un jeu de données plus petit et ciblé, ce qui améliore la précision et le style pour ce cas d'usage.Voir la définition complète → métier ni retrieval-augmented generationretrieval-augmented generationMéthode qui permet à un modèle d'IA de répondre à partir de vos propres documents, en récupérant les passages pertinents avant de générer une réponse.Voir la définition complète → (RAG) l'ancrant dans la bibliothèque de précédents du cabinet.

Comparaison simple du coût total de possession (TCOTCOTotal Cost of Ownership, coût total de possession incluant acquisition, implémentation, maintenance, formation et évolution d'un outil sur sa durée de vie.) sur trois ans :

• Fournisseur : 150 000 $ x 3 = 450 000 $
• Build : 40 000 $ + (20 000 $ x 3) = 100 000 $

Sur le seul critère du coût, le build l'emporte d'environ 350 000 $ sur trois ans (estimation illustrative, pas une prévision). Mais cela ignore les quatre autres dimensions de la grille. Si la précision du build se situe à 65 % au lieu de 85 %, le cabinet paie ailleurs : temps d'associé à revérifier les sorties, risque sur la confiance client, exposition potentielle à la faute professionnelle. Les comparaisons de coûts sans ajustement pour la précision et le risque sont incomplètes, et c'est l'erreur la plus fréquente dans ce type de décision.

Quand construire, quand acheter

Acheter quand :

• La tâche est courante dans le secteur (revue de contrats, e-discovery, transcription) et des fournisseurs matures existent avec un historique. Exemples en legal tech : Harvey, Relativity, Luminance ; en comptabilité, les outils construits au-dessus des add-ons IA des grands éditeurs d'ERP.
• Votre cabinet n'a pas la capacité d'ingénierie IA en interne pour maintenir un pipeline de modèles de façon responsable.
• La rapidité de déploiement compte plus que la personnalisation.

Construire quand :

• Le workflow est propre à la pratique de votre cabinet (un domaine réglementaire de niche, une méthodologie propriétaire) et aucun fournisseur ne le traite correctement.
• Vous disposez de personnel technique capable de maintenir l'outil sur la durée, pas seulement de le lancer.
• La sensibilité des données est telle que même un traitement par un tiers validé est exclu (rare, mais réel pour certains travaux liés au secteur public ou à la défense).

Hybride (de plus en plus courant en 2026) : licencier une API de foundation model (OpenAI, Anthropic, Google ou équivalent) mais construire la couche de retrieval et l'intégration en interne. Cela donne la qualité du modèle sans lock-in fournisseur complet, au prix d'une vraie appropriation technique en interne.

Mener un vrai pilote, pas une démo

Quelle que soit l'option vers laquelle vous penchez, exigez un pilote avec vos propres données avant de signer un engagement pluriannuel :

• Utilisez des dossiers réels caviardés ou anonymisés, pas les données d'exemple du fournisseur.
• Faites noter les sorties à l'aveugle par les professionnels qui utiliseront réellement l'outil (les collaborateurs, pas seulement les associés), en comparant la production de l'IA au travail humain sans savoir lequel est lequel.
• Fixez un seuil chiffré à l'avance : par exemple, « la sortie doit correspondre au jugement du réviseur senior sur au moins 80 % des clauses signalées » (seuil illustratif, définissez le vôtre selon votre tolérance au risque).
• Bornez la durée : 30 à 60 jours, puis un go/no-go formel avec les totaux de la grille sous les yeux des associés.

Pour une introduction en langage clair à l'évaluation de la fiabilité d'un système d'IA avant déploiement, le NIST AI Risk Management Framework (National Institute of Standards and Technology américain) est une ressource solide, gratuite et indépendante des fournisseurs, applicable bien au-delà du secteur public.

🎬 [VIDEO: "Build vs Buy: The AI Decision Every Company Faces" - youtube.com - un framework pratique pour arbitrer entre développement IA interne et solutions fournisseurs, applicable à l'ensemble des contextes de services professionnels]

Points clés à retenir

• Notez les options fournisseur et build sur les mêmes quatre dimensions : sécurité des données, précision métier, intégration et coût total de possession. Ne laissez pas les fournisseurs fixer les termes de la comparaison.
• Les comparaisons de coûts sont incomplètes sans ajustement pour la précision et le risque. Un outil moins cher mais plus souvent faux peut coûter davantage en temps de revue par les associés et en risque client.
• Achetez pour les cas d'usage courants et matures (revue de contrats, e-discovery) ; construisez uniquement quand le workflow est réellement unique et que vous avez le personnel pour le maintenir sur la durée.
• Faites toujours un pilote avec vos propres données réelles (caviardées) avant de signer un contrat pluriannuel ou de valider un build. La performance en démo et la performance en production sont deux choses différentes.
• Les approches hybrides, licencier un foundation model mais construire sa propre couche d'intégration, s'imposent de plus en plus comme le juste milieu pratique en 2026.