Acheter ou construire l'IA : outil SaaS, API ou sur mesure

3 démos d'éditeurs sont calées la semaine prochaine, le CEO veut un plan IA avant le conseil d'administration, et quelqu'un dans l'équipe a déjà bricolé un prototype avec une clé API un week-end. La question posée, c'est acheter ou construire. Ce n'est pas par là qu'il faut commencer.

Il y a 3 options, pas 2. Vous pouvez acheter un outil SaaS, appeler un modèle par API et le brancher dans votre propre produit, ou construire un système sur mesure autour de vos données et de vos processus.

Achetez un outil SaaS quand la tâche est générique et interne. Intégrez une API quand la fonctionnalité vit dans votre produit mais que l'intelligence reste générique. Construisez sur mesure quand au moins deux de ces conditions sont réunies : l'IA fait votre différence, elle tourne sur vos propres données, à fort volume, ou elle va loin dans vos systèmes.

Voici comment nous les départageons, en commençant par l'étape que la plupart des équipes sautent.

Écrire le besoin d'abord

Avant de comparer quoi que ce soit, écrivez un paragraphe : qui l'utilise, ce qui entre, ce qui sort, combien de fois par jour, et ce qui se passe quand la réponse est fausse. Cela prend une heure. Cela évite des semaines de démos.

Ce paragraphe tranche souvent la moitié de la question à lui seul. « Notre équipe commerciale veut des comptes rendus de réunion dans le CRM » n'est pas le même problème que « nos clients posent 2 000 questions par jour sur leurs contrats ». Le premier, c'est sans doute un abonnement ; le second, sans doute pas.

La dernière partie compte le plus. Si une mauvaise réponse coûte 10 secondes à un collègue, vous pouvez acheter presque n'importe quoi. Si elle coûte un client, un contrat ou un problème de conformité, il vous faut la main sur la façon dont la réponse est produite.

Quand un outil SaaS suffit

Achetez quand la tâche est la même chez vous que partout ailleurs. Prise de notes en réunion, transcription, aide à la rédaction, tri des tickets de premier niveau, recherche dans un drive partagé. Les éditeurs les ont déjà construits, et toute une équipe améliore cette seule fonctionnalité chaque mois.

Les signes qu'un outil SaaS est le bon choix :

• les utilisateurs sont vos équipes, pas vos clients
• l'outil fonctionne avec les logiciels que vous payez déjà
• personne ne remarquerait un changement d'éditeur l'an prochain
• les données qu'il manipule ont le droit de quitter vos systèmes, aux conditions de l'éditeur

Avant de signer, demandez à l'éditeur de faire tourner l'outil sur 50 de vos vrais documents, pas sur son jeu de démo. L'écart entre les deux, c'est le travail que vous ferez dans des tableurs 6 mois plus tard.

Le coût, c'est un abonnement par utilisateur et un après-midi de paramétrage. Le coût caché, c'est la dépendance aux workflows, pas aux données : vérifiez comment récupérer votre historique avant de déployer l'outil auprès de 200 personnes.

Quand une intégration API suffit

Intégrez quand la fonctionnalité a sa place dans votre produit ou vos outils internes, mais que l'intelligence elle-même est générique. Résumer un document, extraire les champs d'une facture, classer un e-mail, rédiger une réponse qu'une personne relit. L'API d'un fournisseur de modèles fait la partie difficile ; votre code fait le reste.

Ce « reste » représente l'essentiel du travail, et c'est là que les équipes sous-estiment l'effort. L'appel au modèle tient en quelques lignes. Autour, il vous faut :

• le bon contexte envoyé avec chaque requête, tiré de vos propres systèmes
• un moyen de vérifier la réponse avant qu'elle n'arrive à un utilisateur
• des logs, pour voir ce qui a été demandé et ce qui est revenu
• un plafond de coût, parce qu'une tarification à l'usage grimpe avec votre trafic
• une solution de repli quand le fournisseur est lent ou en panne

La durée d'une intégration de ce type dépend de la profondeur à laquelle elle entre dans vos systèmes. Une première version entièrement sur mesure prend plus longtemps : sur nos projets, en général 3 à 6 semaines après le lancement.

Vérifiez deux points avant de vous engager. D'abord, où vont les données : certains fournisseurs traitent les requêtes aux États-Unis par défaut, et plusieurs proposent désormais un hébergement en Europe ou un déploiement dans votre propre compte cloud. Ensuite, comment vous changerez de modèle plus tard : gardez le fournisseur derrière une seule couche de votre code, pour qu'en changer soit une question de configuration et pas une réécriture.

Quand le sur mesure vaut le coup

Sur mesure ne veut pas dire entraîner votre propre modèle. Pour la plupart des entreprises, c'est un système construit autour de modèles existants : vos pipelines de données, votre recherche documentaire, votre évaluation, votre interface, vos règles. Il devient rentable quand 2 de ces 4 conditions sont vraies. Une seule est une raison de regarder de plus près, pas de construire.

C'est votre différence. Si la fonctionnalité est la raison pour laquelle vos clients vous choisissent plutôt qu'un concurrent, la louer au même éditeur que lui revient à lui céder l'avantage. Vous voulez maîtriser le comportement, la roadmap et la vitesse à laquelle elle s'améliore.

Vos données font la valeur. Quand la réponse dépend d'années de documents internes, de données produit ou d'historique client, le travail consiste à préparer ces données, à les tenir à jour et à contrôler qui voit quoi. Aucun outil sur étagère ne connaît votre modèle de droits d'accès.

Le volume change le calcul. À faible volume, la tarification par utilisateur ou par appel coûte peu. À fort volume, la facture mensuelle peut dépasser le coût de construire et de faire tourner votre propre système. Faites le calcul sur le volume de l'an prochain, pas sur celui de ce mois-ci.

L'intégration va loin. Une fonctionnalité qui lit dans 3 systèmes internes, écrit dans 2 autres et doit respecter des règles métier à chaque étape n'est pas un plugin. C'est du logiciel, et il faut le construire et le maintenir comme le reste de votre produit.

Une première version sur mesure coûte plus cher au départ qu'une intégration, puis ajoute un coût mensuel de fonctionnement. C'est ce coût de fonctionnement que la plupart des budgets oublient.

Il faut quelqu'un pour le faire tourner : surveiller les réponses, mettre à jour les prompts et les données, suivre les nouvelles versions de modèles, corriger ce qui dérive. Prévoyez-le dans le budget dès le premier jour, et posez une question à tout partenaire avant de signer : qui le fait tourner au troisième mois ? La plupart des devis s'arrêtent au lancement.

Notre réponse : la même équipe, qui reste pour le suivi, les améliorations et l'itération suivante, ou une passation propre à la vôtre.

Acheter ou construire l'IA : la grille de décision

Lisez le tableau ligne par ligne. La ligne qui tranche, c'est en général « Risque principal », pas le coût.

La plupart des entreprises finissent avec les trois, pour des besoins différents. L'erreur, c'est de choisir une seule réponse pour toute l'entreprise, en général celle que l'équipe trouvait la plus intéressante à construire.

Un ordre raisonnable : achetez pour la productivité interne, intégrez là où une fonctionnalité doit vivre dans votre produit, et gardez le sur mesure pour les un ou deux endroits où il change vos chiffres. Commencez par la plus petite version qui arrive en production, mesurez-la, puis décidez si elle mérite davantage.

Un avis extérieur avant de signer

C'est la question que nous traitons pendant un audit gratuit. Apportez le paragraphe de la première partie : en une heure, nous passons en revue votre activité, puis vous recevez un document court qui dit quoi acheter, quoi intégrer, quoi construire, et ce que nous vous déconseillons. Réservez un audit gratuit avant de signer avec un éditeur ou de constituer une équipe projet.