IA en entreprise : ne choisissez pas un modèle, choisissez une stratégie

Il y a aujourd'hui un vrai boucan autour de l'intelligence artificielle. Claude sort une nouveauté, OpenAI pousse Codex, Mistral renforce ses offres entreprise, Microsoft intègre Copilot dans l'écosystème de travail, les modèles chinois comme Qwen ou DeepSeek avancent vite, et chaque semaine apporte son lot de benchmarks, de posts LinkedIn et de promesses de productivité.

Pour un dirigeant, ce bruit crée une illusion dangereuse : celle qu'il faudrait absolument choisir le meilleur modèle du moment. En réalité, le bon sujet est ailleurs. Une entreprise n'a pas besoin d'épouser un modèle. Elle a besoin d'une stratégie IA capable de créer de la valeur, de protéger les données, de garder les coûts sous contrôle et de rester mobile quand le marché change.

C'est aussi l'approche que je détaille sur ma page dédiée à l'accompagnement IA à Bordeaux : partir du besoin métier, cadrer l'architecture, puis seulement choisir les briques IA, RAG, automatisation ou Azure OpenAI qui ont du sens.

Le bruit IA n'est pas une stratégie

Le marché est devenu volontairement difficile à suivre. OpenAI présente Codex comme un agent capable d'aider à écrire, relire et livrer du code. Mistral met en avant Le Chat Enterprise avec administration, gouvernance et sécurité à l'échelle des organisations. Microsoft documente des mécanismes de gouvernance dans Copilot Studio. GitHub Copilot, Claude Code, Gemini, Qwen et les alternatives open source ajoutent encore d'autres options.

Ce foisonnement est une bonne nouvelle : il crée de la concurrence, accélère l'innovation et donne plus de choix. Mais il rend aussi le pilotage plus complexe. Un comité de direction ne peut pas bâtir sa transformation IA sur la dernière démo virale ou sur un score de benchmark isolé.

Les benchmarks ont leur utilité, mais ils ne répondent pas aux questions qui comptent en entreprise : intégration aux outils existants, confidentialité, coût par workflow, qualité des logs, supervision humaine, maintien en condition opérationnelle, réversibilité et capacité à auditer une décision.

Le coût réel arrive après l'enthousiasme

À l'échelle individuelle, l'IA semble presque donnée. Un abonnement à quelques dizaines ou centaines d'euros par mois permet de lancer des sessions longues, d'utiliser des agents, de générer du code, de traiter des documents ou d'automatiser une partie du travail. Mais ce prix visible ne raconte pas toute l'histoire.

L'Agence internationale de l'énergie rappelle que les data centers IA deviennent un poste électrique majeur : les centres hyperscale orientés IA peuvent dépasser 100 MW de puissance, et la demande électrique des data centers a fortement progressé en 2025. Autrement dit, le coût physique existe déjà. Il n'est pas toujours pleinement visible dans les abonnements actuels.

Dans une entreprise, ce sujet devient vite du FinOps IA. Si un assistant interne est utilisé par 20 personnes, le risque est limité. S'il devient une brique centrale pour le support, la vente, le reporting, la conformité ou la production documentaire, chaque appel API, chaque token de sortie, chaque réindexation RAG et chaque automatisation peut devenir une ligne de coût récurrente.

Le risque de lock-in IA

Le verrouillage fournisseur existe déjà dans la data : plateformes cloud, entrepôts de données, outils BI, orchestrateurs, formats propriétaires. Avec l'IA, il peut devenir encore plus rapide, parce que les modèles s'invitent directement dans les processus métier.

Si vos workflows, vos prompts, vos agents, vos connecteurs et vos évaluations sont trop dépendants d'un seul éditeur, vous perdez votre capacité de négociation. Si le prix augmente, si les limites d'usage changent, si la latence se dégrade ou si une contrainte réglementaire apparaît, votre entreprise doit pouvoir pivoter.

Les limites de débit documentées par Anthropic, par exemple, rappellent que la capacité est une ressource pilotée. Ce n'est pas un problème propre à un acteur : tout fournisseur IA doit arbitrer entre demande, infrastructure, abus, coût et qualité de service.

Partir du besoin métier, pas de l'envie d'IA

La transformation IA commence rarement par un modèle. Elle commence par une phrase simple : "quel problème voulons-nous résoudre ?" Dans beaucoup de cas, une bonne UX, une règle métier claire, une automatisation classique ou un meilleur pipeline de données suffisent. L'IA n'est pas nécessaire partout.

Un traitement OCR peut parfois utiliser un petit modèle spécialisé. Une classification d'emails peut fonctionner avec un modèle léger et des règles de confiance. Un assistant documentaire RAG a besoin d'une gouvernance documentaire robuste avant d'avoir besoin du plus gros modèle disponible. Un agent de développement ou d'analyse complexe peut justifier un modèle premium, mais seulement sur les tâches où la valeur créée compense le coût.

C'est aussi le message de mon comparatif des LLM de coding 2026 : le meilleur choix dépend du contexte, du coût de sortie, de la stabilité et de l'usage réel, pas seulement du prestige du modèle.

Définir un MVP et des objectifs mesurables

Un projet IA ne devrait pas démarrer avec une ambition floue du type "transformer l'entreprise avec l'IA". Il doit commencer par une cible MVP : la plus petite version utile qui prouve une valeur métier réelle. Pas une démo spectaculaire. Pas un prototype qui marche uniquement devant le comité de pilotage. Un outil assez simple pour être livré vite, utilisé par de vrais utilisateurs et évalué avec des chiffres.

C'est ici que beaucoup de projets se perdent. RAND rappelle que, selon certaines estimations, plus de 80% des projets IA échouent, soit environ deux fois le taux d'échec des projets IT classiques. Le rapport MIT NANDA 2025, très cité sur la GenAI en entreprise, indique de son côté qu'environ 95% des pilotes étudiés ne produisent pas d'impact mesurable sur le P&L. Ce chiffre ne veut pas dire que toute IA est inutile. Il dit surtout qu'un projet sans cible, sans intégration métier et sans mesure de valeur devient vite un gouffre budgétaire.

Avant de financer un agent IA, un RAG documentaire ou une automatisation, il faut donc écrire la cible en termes quantifiables. Par exemple : réduire de 30% le temps de traitement d'une demande, diminuer de 15% le coût de support sur un périmètre donné, passer d'un délai de réponse de deux jours à deux heures, atteindre 90% de réponses sourcées sur un corpus documentaire validé, ou maintenir un coût inférieur à X euros par dossier traité.

Le MVP doit aussi avoir des critères d'arrêt. Si l'outil n'est pas utilisé, si le coût par action explose, si les utilisateurs passent plus de temps à corriger qu'à gagner du temps, ou si la qualité ne dépasse pas un seuil défini, il faut savoir arrêter, pivoter ou revenir à une automatisation plus classique. Un bon projet IA n'est pas celui qui va le plus loin dans la hype. C'est celui qui sait prouver vite qu'il mérite d'être industrialisé.

Gouvernance, données et conformité

La gouvernance IA n'est pas un sujet administratif. C'est ce qui permet à une entreprise de passer de l'expérimentation à l'industrialisation. Le NIST AI Risk Management Framework propose une logique utile : gouverner, cartographier, mesurer et gérer les risques. En Europe, l'AI Act ajoute une approche par niveau de risque. La CNIL rappelle aussi que les projets IA doivent être pensés avec le RGPD dès la conception.

Concrètement, une gouvernance IA doit répondre à des questions très opérationnelles : quelles données peuvent être envoyées à un modèle externe ? quelles données doivent rester en local ? qui approuve un agent avant sa mise en production ? comment tracer les réponses ? comment gérer les droits d'accès dans un RAG documentaire ? comment auditer une automatisation qui agit dans un CRM ou un outil métier ?

Sans ces règles, l'entreprise accumule de la dette IA : prompts dispersés, données copiées dans des outils non maîtrisés, agents sans propriétaire, coûts invisibles, décisions non traçables. Avec ces règles, l'IA devient une capacité d'entreprise, pas une collection de tests isolés.

Architecture agnostique : le LLM doit devenir une commodité

Une bonne architecture IA doit pouvoir changer de modèle sans réécrire toute l'application. Cela ne veut pas dire que tous les modèles se valent. Cela veut dire que l'entreprise doit garder la maîtrise de ses couches critiques : données, prompts, évaluation, sécurité, observabilité et workflows.

Dans la pratique, je recommande souvent une couche de routage ou d'abstraction : un modèle rapide pour les tâches simples, un modèle premium pour les raisonnements complexes, un modèle européen ou local pour les données sensibles, et des tests d'évaluation communs pour comparer la qualité. Le RAG, les connecteurs et les logs doivent rester sous contrôle de l'entreprise.

Cette approche ouvre aussi des options de souveraineté. Selon les contraintes, on peut utiliser Azure OpenAI, un fournisseur européen, Mistral, un modèle open source hébergé en France, ou un GPU loué ponctuellement pour un traitement sensible. L'important est de ne pas découvrir cette question le jour où le fournisseur principal change ses règles.

Une roadmap IA 30 / 60 / 90 jours pour dirigeants

Pour une PME, une ETI ou une direction métier, je préfère une trajectoire courte et concrète plutôt qu'un grand programme abstrait.

Depuis Bordeaux, j'accompagne les entreprises de toutes tailles dans ce cadrage : audit IA, agents IA, RAG documentaire, automatisation métier, gouvernance data, Azure OpenAI, Microsoft Fabric et trajectoires cloud plus souveraines quand le contexte l'exige.

La bonne transformation IA ne consiste pas à courir derrière tous les modèles. Elle consiste à rendre l'entreprise plus rapide, plus fiable et plus lucide, sans perdre la maîtrise de ses données, de ses coûts et de ses choix futurs.

Sources

Sources utilisées : IEA sur énergie et IA, IEA sur la demande électrique des data centers, NIST AI RMF, AI Act européen, CNIL IA et RGPD, RAND sur les causes d'échec des projets IA, MIT NANDA GenAI Divide, OpenAI Codex, Mistral Le Chat Enterprise, Microsoft Copilot Studio governance et Anthropic rate limits.