Construire ou acheter une solution IA : la décision commence après la démonstration

Une démonstration d'IA peut être convaincante en une heure. Un système qui traite des données métier, répond à des utilisateurs réels et reste exploitable deux ans plus tard pose une autre question. C'est là que l'opposition entre « construire » et « acheter » devient utile, à condition de ne pas la réduire à un duel entre une équipe technique et un fournisseur.

Acheter une solution est parfois le choix le plus sobre. Si l'usage est largement standardisé, si les données ne doivent pas quitter un cadre maîtrisé et si le fournisseur offre les garanties nécessaires, recréer la même fonction en interne n'apporte pas forcément de valeur. Construire devient pertinent lorsque l'outil porte une logique métier difficile à acheter, s'appuie sur des données singulières ou doit s'intégrer à des décisions que l'entreprise ne peut déléguer sans perdre la main.

Le mauvais départ consiste à choisir un produit avant d'avoir décrit le travail que l'on veut améliorer. Une IA de synthèse, de classification ou d'assistance ne mérite pas automatiquement une plateforme dédiée. À l'inverse, un abonnement qui semble léger au départ peut devenir une dépendance coûteuse s'il s'installe au centre d'un processus critique sans règle de sortie. Un diagnostic et accompagnement IA a d'abord pour objet de mettre ce périmètre au clair : qui utilise le système, sur quelles données, pour produire quelle décision ou quel acte.

L'achat est un choix d'exploitation, pas un renoncement

On achète une brique lorsqu'elle répond à un besoin commun sans forcer l'organisation à réinventer ce qui existe déjà. Traduction, transcription, extraction de données sur un format stable, assistance bureautique : la rapidité de mise à disposition et la maintenance opérée peuvent peser plus lourd que la propriété du code. L'entreprise doit néanmoins regarder au-delà de la licence. Les conditions d'usage des données, l'évolution tarifaire, les limites d'API, les accès administrateurs, les journaux disponibles et la réversibilité font partie du produit.

Un achat sérieux demande donc des exigences précises. Peut-on exporter les données et les configurations dans un format utilisable ? Les rôles peuvent-ils être raccordés à l'annuaire de l'entreprise ? Le contrat dit-il ce qui advient des contenus transmis et des sorties générées ? Le fournisseur annonce-t-il les changements qui peuvent modifier le comportement du système ? Ces questions sont moins spectaculaires qu'une comparaison de modèles, mais elles déterminent la liberté de changer d'outil.

La sensibilité des données peut faire basculer la décision. Ce n'est pas une raison pour déclarer toute solution externe impossible ; c'est une raison pour définir le niveau de contrôle requis. Les recommandations de la CNIL sur les systèmes d'IA fournissent un point d'appui : finalité claire, minimisation, sécurité et gouvernance ne sont pas des formalités ajoutées après coup. Elles influencent l'architecture, les fournisseurs admissibles et les données qu'un pilote peut réellement utiliser.

Construire suppose d'assumer ce qui suit le prototype

Construire ne veut pas forcément dire entraîner un modèle maison. Dans la plupart des projets, la valeur se trouve plutôt dans l'assemblage : connecter les sources de données, formaliser les règles métier, mettre en place les droits d'accès, évaluer les réponses et intégrer l'outil dans un parcours de travail. Ce sont ces couches qui restent lorsque le modèle sous-jacent change.

Le coût d'un développement ne s'arrête donc pas à sa première version. Il comprend la supervision, la sécurité, les correctifs, la documentation, les tests à chaque évolution de modèle et les personnes capables de reprendre le système. Le AI Risk Management Framework du NIST propose de gérer, mesurer et gouverner les risques durant tout le cycle de vie. Pour un dirigeant, cette logique a une traduction simple : un budget de construction sans budget d'exploitation n'est pas un budget complet.

Construire est cohérent quand l'entreprise sait aussi qui possédera le produit après sa livraison. Le métier doit pouvoir qualifier les réponses et signaler les exceptions. L'informatique doit pouvoir faire évoluer les connecteurs et les identités. La direction doit avoir arrêté les règles de responsabilité. Sans cette répartition, un projet sur mesure peut seulement déplacer la dépendance : du fournisseur de logiciel vers le prestataire ou vers un salarié devenu indispensable.

C'est aussi la raison pour laquelle les choix d'IA souveraine doivent être formulés concrètement. Héberger dans un environnement européen, sélectionner des composants réversibles ou maîtriser les journaux peut être décisif pour un usage sensible. Cela ne dispense ni de l'intégration ni de l'évaluation. La souveraineté désigne une capacité à décider et à changer, pas une étiquette collée sur une infrastructure.

La voie hybride a un sens lorsque la frontière est nette

Beaucoup d'entreprises n'ont pas à choisir une seule doctrine. Elles peuvent acheter les composants devenus ordinaires et concentrer le développement sur le flux qui les différencie. Un modèle accessible par API peut servir à un pilote ; les règles d'accès, les données métier et les critères d'évaluation restent sous contrôle. Le système gagne alors en souplesse sans prétendre posséder chaque brique technique.

Cette option ne fonctionne que si la frontière est écrite. Quelle donnée reste dans le système interne ? Quel composant peut être remplacé ? À quel moment une intervention humaine est-elle obligatoire ? Quels résultats permettent de poursuivre ou d'arrêter le pilote ? Une démarche menée avec un partenaire IA capable d'aller du cadrage au déploiement peut rendre ces décisions vérifiables, plutôt que les laisser dans des présentations commerciales.

L'Europe ajoute un cadre qui rend cette discipline plus urgente. Le règlement européen sur l'IA ne commande pas à chaque entreprise de construire son modèle. Il oblige en revanche les acteurs concernés à comprendre leur rôle dans la chaîne de valeur et à organiser leurs responsabilités. Le choix d'architecture ne peut plus être séparé de cette question.

La bonne décision n'est donc pas celle qui affiche le plus vite un assistant. C'est celle qui laisse l'entreprise capable d'expliquer pourquoi l'outil existe, de le faire évoluer et, si nécessaire, de s'en séparer. Avant toute démo, il faut répondre à une question moins flatteuse mais plus utile : quelle part de notre fonctionnement voulons-nous vraiment confier, et laquelle devons-nous rester capables d'opérer ?