Un cabinet comptable de 40 personnes à Chicago a reçu le trimestre dernier une question pointue du conseil juridique externe d’un nouveau client : pouvez-vous confirmer qu’aucun de nos dossiers fiscaux ne sera traité sur un serveur hors des États-Unis ? L’outil de revue documentaire assistée par IA du cabinet tournait sur une API de cloud public, sans garantie contractuelle sur le lieu réel de l’inférence. Personne en interne ne pouvait répondre avec certitude, et le client est parti.
Cette scène se rejoue en ce moment dans tous les secteurs, des deux côtés de l’Atlantique. Un groupe de santé qui évalue un assistant de prise de notes IA doit penser à HIPAA et aux business associate agreements avant de penser à la précision de la transcription. Un gérant d’actifs de taille moyenne à Londres doit penser à l’AI Act européen et au RGPD avant de se demander quel modèle rédige le résumé le plus propre. La question était : quel outil d’IA fonctionne le mieux ? Elle devient : où l’outil tourne-t-il, et qui d’autre peut atteindre les données pendant ce temps ?
Toutes les PME n’ont pas à réagir en installant un serveur GPU dans un local technique. Mais le calcul autour d’une IA qui tourne sur une infrastructure que vous contrôlez, plutôt que louée au token auprès d’un fournisseur que vous ne contrôlez pas, a assez évolué en dix-huit mois pour mériter un examen honnête : ce qui est possible aujourd’hui, ce qu’il faut pour bien l’exploiter, et quand l’API publique reste le choix le plus malin et le moins cher.
Pourquoi « où vont les données » est devenu une question contractuelle
La confidentialité des dossiers clients est le déclencheur le plus fréquent. Cabinets d’avocats, cabinets comptables, gérants de fortune indépendants et prestataires de santé manipulent tous des dossiers qu’ils sont contractuellement ou déontologiquement tenus de protéger, et « ça part vers une API tierce » n’est plus une réponse satisfaisante pour un nombre croissant de clients, d’assureurs et d’auditeurs.
La réglementation donne du mordant à cette intuition. En Europe, le RGPD encadre tout traitement de données personnelles de résidents de l’UE, quel que soit le pays où l’entreprise est établie, et l’AI Act européen ajoute par-dessus des obligations de transparence et de gestion des risques, avec des obligations par niveau de risque échelonnées jusqu’en 2026 et 2027. Aux États-Unis, HIPAA couvre les informations de santé protégées de bout en bout : une entité couverte doit avoir signé un business associate agreement avec tout fournisseur d’IA avant qu’une donnée patient ne le touche. Les institutions financières américaines portent une obligation parallèle au titre de la Safeguards Rule du Gramm-Leach-Bliley Act, qui fait de la surveillance des fournisseurs un devoir légal permanent plutôt qu’une case cochée à la signature.
La juridiction complique encore les choses. Un serveur physiquement installé à Francfort ou à Dublin ne place pas automatiquement les données hors de portée du droit américain si l’entreprise qui l’exploite est américaine : le CLOUD Act permet aux autorités américaines d’exiger la divulgation de données de tout fournisseur américain, où que soient ses serveurs. Pour une entreprise européenne qui traite des données sous le RGPD, le conflit est bien réel, et les autorités de protection des données de plusieurs pays de l’UE le disent publiquement.
Deux autres pressions relèvent moins de la conformité que du bon sens commercial. Le verrouillage fournisseur est réel : tarifs, limites de débit et disponibilité des modèles échappent à votre contrôle dès qu’un workflow est entièrement construit autour de l’API d’un seul fournisseur. Et des coûts au token qui semblent dérisoires en phase pilote peuvent s’accumuler vite à volume de production soutenu, une dynamique à modéliser honnêtement avant de s’engager (le calcul concret arrive plus bas).
C’est exactement le genre de contrainte qui façonne la manière dont un service d’ingénierie IA intégrée cadre un projet dès la première réunion. Que le contrôle de l’infrastructure soit une préférence ou une exigence ferme change l’architecture avant même la première ligne de code.
Ce qui tourne réellement bien hors d’une API publique aujourd’hui
La technologie a évolué assez vite en 2025 et 2026 pour rendre presque inutilisables les conseils d’il y a deux ans. Une poignée de familles de modèles open-weight rivalisent désormais avec les modèles propriétaires de pointe sur les tâches qui composent l’essentiel des charges de travail des PME : questions-réponses sur documents, classification, rédaction, synthèse et extraction de données structurées.
La famille Llama 4 de Meta, sortie en avril 2025, comprend Scout, un modèle mixture-of-experts à 17 milliards de paramètres actifs qui tient sur un seul GPU haut de gamme une fois quantifié, et une variante Maverick plus grande. Mistral a publié Large 3 en décembre 2025, un modèle mixture-of-experts de 675 milliards de paramètres (41 milliards actifs par passage) sous la licence permissive Apache 2.0, la même licence qu’Alibaba a retenue pour Qwen 3.5, déployé par vagues entre février et mars 2026. Le suisse Apertus, construit par l’ETH Zurich, l’EPFL et le Centre national suisse de calcul scientifique (CSCS) et publié en septembre 2025, va encore plus loin : ses poids, ses données et son code d’entraînement sont tous publics, et il a été conçu explicitement avec les obligations de transparence de l’AI Act européen en tête.
| Famille de modèles | Sortie | Intérêt pour les PME | Licence |
|---|---|---|---|
| Llama 4 (Meta) | Avril 2025 | La variante Scout tourne sur un seul GPU haut de gamme une fois quantifiée ; très grande fenêtre de contexte | Gratuite, avec restrictions d’usage au-delà de 700 M d’utilisateurs actifs mensuels |
| Mistral Large 3 | Décembre 2025 | 41 milliards de paramètres actifs sur 675 au total ; solide raisonnement généraliste | Apache 2.0 |
| Qwen 3.5 (Alibaba) | Fév.-mars 2026 | Très bonnes performances multilingues et en code ; des variantes denses plus petites sont aussi sorties | Apache 2.0 |
| Apertus (ETH Zurich / EPFL / CSCS) | Septembre 2025 | Entièrement ouvert, données d’entraînement comprises ; conçu avec les règles de transparence européennes en tête | Apache 2.0 |
Ce tableau n’est qu’un instantané. De nouvelles versions arrivent tous les quelques mois, les benchmarks bougent, et les licences comptent autant que la capacité brute : la licence communautaire de Llama est gratuite pour l’écrasante majorité des PME, mais ajoute des restrictions d’usage et une exigence d’attribution que les alternatives sous Apache ne portent pas. Quel que soit le modèle choisi aujourd’hui, budgétez son remplacement d’ici douze à dix-huit mois.
Le matériel entièrement on-premise n’est pas la seule option, et pour la plupart des PME il ne devrait pas être la première envisagée. Un déploiement en cloud privé, c’est-à-dire une instance GPU dédiée louée à un fournisseur européen ou américain sous un vrai contrat de traitement des données et dans une juridiction connue, apporte l’essentiel du bénéfice de souveraineté sans l’investissement initial ni la charge de maintenance de vos propres serveurs. Le tout-on-premise ne justifie généralement son coût que lorsque même un environnement cloud dédié est inacceptable, ce qui en pratique vise surtout les charges les plus régulées de la santé, de la finance ou du secteur public.
Pourquoi le déficit de compétences arrête les PME avant le budget matériel
Acheter un GPU est la partie facile. Une seule carte capable de faire tourner un modèle de 20 à 70 milliards de paramètres bien quantifié coûte entre 25 000 et 70 000 dollars selon la configuration, ou se loue chez un fournisseur de GPU cloud pour environ 1 à 4 dollars de l’heure selon la carte et le prestataire. Ça, c’est une ligne budgétaire. Le plan projet, c’est tout ce qui vient après.
Ce qui détermine si un déploiement auto-hébergé fonctionne, c’est un ensemble de disciplines d’ingénierie continues dont la plupart des PME n’ont jamais eu besoin jusqu’ici :
- Dimensionnement du matériel. Faire correspondre taille de modèle, niveau de quantification et nombre d’utilisateurs simultanés attendus à une configuration GPU précise, puis refaire ce calcul à chaque changement de modèle.
- Choix du modèle. Sélectionner un modèle sur votre tâche et votre langue réelles plutôt que sur un score obtenu sur un benchmark que votre entreprise ne croisera jamais.
- Retrieval sur vos propres documents. Obtenir d’un modèle performant qu’il réponde à des questions sur des PDF internes en désordre, des tableurs et des e-mails est un problème de recherche et de classement avant d’être un problème de langue. Un retrieval naïf produit des réponses fausses et sûres d’elles plus souvent qu’on ne l’imagine.
- Évaluation. Un jeu de test de vraies questions aux réponses validées, exécuté avant chaque changement de modèle ou de prompt, est le seul moyen fiable d’attraper une régression avant qu’un client ne s’en charge.
- Monitoring. Suivre la latence, le coût et la qualité des réponses en production. La disponibilité seule ne vous dira pas si les réponses sont encore bonnes.
- Mises à jour. De nouvelles versions de modèles arrivent tous les quelques mois, et chacune doit être réévaluée sur votre jeu de test avant d’approcher la production, typiquement quelques jours d’ingénieur par mise à jour.
Une étude du MIT a constaté qu’environ 95 % des pilotes d’IA générative en entreprise n’avaient aucun effet mesurable sur le compte de résultat, et a attribué les échecs surtout à des lacunes d’intégration plutôt qu’à la qualité des modèles (sa méthodologie a été contestée, prenez le chiffre comme une tendance plus que comme une mesure précise). Les déploiements auto-hébergés échouent de la même manière : le modèle brille en démo, puis se dégrade discrètement face aux vrais documents et aux cas limites que les utilisateurs tapent réellement, et personne ne s’en aperçoit avant un client.
Une équipe de data science est surdimensionnée pour cela. Une seule personne qui l’a déjà fait suffit : quelqu’un qui dimensionne le matériel correctement du premier coup et fait fonctionner le retrieval sur votre vrai fonds documentaire, et qui installe l’habitude de l’évaluation avant la mise en service plutôt qu’après la première réponse fausse embarrassante.
Quand l’API gagne encore, et quand le local se rentabilise
Faites les calculs avant toute décision. Mi-2026, la tarification des API de pointe va d’environ 0,10 à 25 dollars par million de tokens selon le modèle et le sens (l’entrée coûte généralement moins cher que la sortie), et pour la plupart des PME en pilote ou en début de production, c’est une erreur d’arrondi à côté de la masse salariale. Une équipe support qui répond à 200 questions clients par jour via un pipeline de retrieval sur les documents de l’entreprise, à environ 8 000 tokens de contexte récupéré et de réponse par question, consomme environ 1,6 million de tokens par jour. À un tarif moyen typique de 3 dollars par million de tokens, cela fait moins de 150 dollars par mois, confortablement dans les dépenses logicielles courantes.
Le volume doit grimper bien plus haut qu’on ne l’imagine avant que l’arithmétique ne penche vers l’achat de matériel. Prenons un cas illustratif plus chargé : une entreprise de 60 personnes qui exploite un agent de support client traitant 3 000 conversations par jour, chacune mobilisant environ 4 000 tokens de données produit récupérées, d’historique de conversation et de réponse générée. Cela représente environ 360 millions de tokens par mois. Au même tarif moyen de 3 dollars par million, la facture d’API annuelle s’établit autour de 13 000 dollars, une vraie ligne budgétaire mais encore loin des 40 000 à 70 000 dollars que coûte à l’achat un serveur GPU dédié digne de ce nom. Demandez un vrai devis pour votre modèle, votre volume et votre matériel avant de faire ce calcul pour de bon : ces chiffres illustrent la forme de l’arbitrage, pas un business case abouti.
Cet écart mérite qu’on s’y arrête. Le simple point d’équilibre sur le coût des tokens justifie rarement l’achat de matériel dédié pour une PME typique. Il faudrait un volume d’échelle centre d’appels, soutenu jour et nuit, pour que l’arithmétique seule penche vers la propriété. Ce qui pousse la plupart des PME vers une infrastructure locale ou en cloud privé, c’est l’exigence de contrôler où les données résident physiquement et qui peut y accéder. Le coût devient secondaire une fois cette exigence actée, et à ce stade, louer une instance GPU en cloud privé est généralement plus économique pour la satisfaire que l’achat d’un serveur.
La décision se ramène le plus souvent à deux variables qui comptent pour des raisons différentes : la sensibilité des données, qui décide si vous avez besoin de contrôler l’infrastructure tout court, et le volume traité, qui décide si louer ou acheter est la façon la plus sensée d’y parvenir.
L’API reste la bonne réponse quand :
- Le volume est faible ou irrégulier, quelques milliers de requêtes par mois plutôt que des millions
- Les données ne sont ni réglementées ni contractuellement sensibles
- La vitesse d’itération sur le produit compte plus que le contrôle de l’infrastructure qui le porte
- Personne dans l’équipe ne peut encore prendre en charge les mises à jour de modèles et l’évaluation sur la durée
L’infrastructure locale ou en cloud privé commence à gagner quand :
- Le volume est soutenu et assez prévisible pour dimensionner du matériel
- Les données sont réglementées (dossiers de santé, données financières, secret professionnel) ou portent de vraies obligations contractuelles de confidentialité
- Un client, un assureur ou un auditeur a explicitement exigé une résidence des données ou un lieu de traitement nommé
- Quelqu’un dans l’équipe, ou en cours de recrutement, peut prendre en charge le travail d’ingénierie continu
Pourquoi ce travail exige un ingénieur dans vos murs
Tout ce qui fait fonctionner une IA auto-hébergée se passe dans vos systèmes, avec vos données, et doit être fait par quelqu’un qui comprend le métier aussi bien que l’infrastructure. Dimensionner le matériel sur la charge réelle et régler le retrieval sur vos documents effectifs sont des travaux de l’intérieur, tout comme la veille continue sur la qualité en production. Rien de tout cela ne se cadre depuis un jeu de slides, ni ne se confie comme un livrable ponctuel qu’on laisse ensuite vivre seul.
C’est le modèle vers lequel l’industrie de l’IA a convergé pour ses déploiements les plus difficiles. OpenAI, Anthropic et AWS ont tous constitué des équipes d’implémentation dédiées ces deux dernières années, en grande partie parce que la capacité générique des modèles s’est révélée être les 80 % faciles du problème. Le dernier kilomètre, la partie qui tourne dans le stack d’une entreprise précise, sur ses données et sous ses contraintes, exigeait des ingénieurs intégrés sur site plutôt qu’un ticket de support. Ce schéma porte désormais un nom : le forward deployed engineering. Ce qu’est réellement un forward deployed engineer, et comment ce modèle se compare à un freelance ou à une agence, mérite d’être compris avant de décider qui construira cela pour vous : voir Ingénieur IA intégré vs freelance vs agence.
Si votre entreprise se situe quelque part au milieu, au-delà du point où la simplicité de l’API publique l’emporte sur le risque de conformité, mais sans certitude sur le matériel, le modèle ou l’équipe qu’il faudrait pour l’exploiter vous-mêmes, le sujet vaut une conversation avant un bon de commande. Un appel de 30 minutes peut vous dire honnêtement si l’IA on-premise ou en cloud privé correspond à votre volume et à la sensibilité de vos données, si votre équipe peut la faire tourner dans la durée, ou si rester sur l’API un an de plus est le choix le plus malin.
Questions fréquentes
Une petite entreprise peut-elle vraiment faire tourner sa propre IA, ou l'on-premise n'est-il réaliste que pour les grands groupes ?
Une petite entreprise peut faire tourner des modèles open-weight performants comme Llama 4, Mistral Large 3 ou Qwen 3.5 sur un seul serveur GPU bien dimensionné, ou louer une capacité équivalente auprès d'un fournisseur de cloud privé. Le budget matériel est rarement ce qui vous limite. La ressource rare, c'est une personne capable de dimensionner correctement le déploiement, de régler le retrieval sur vos documents et de continuer à l'évaluer à mesure que les modèles et les données changent.
Auto-héberger un modèle d'IA nous rend-il automatiquement conformes au RGPD ou à HIPAA ?
Non. Faire tourner un modèle sur une infrastructure que vous contrôlez élimine un risque précis, le transfert incontrôlé de données vers un sous-traitant tiers dans une juridiction incertaine, mais il vous faut toujours une base légale pour le traitement, des contrôles d'accès, une journalisation d'audit, et un business associate agreement signé ou son équivalent partout où la réglementation l'exige. L'auto-hébergement est un contrôle parmi d'autres, pas un programme de conformité à lui seul.
Quels modèles open-weight sont réellement assez bons pour remplacer une API payante mi-2026 ?
Llama 4 (Meta, avril 2025), Mistral Large 3 (décembre 2025) et Qwen 3.5 (Alibaba, déployé de février à mars 2026) sont tous compétitifs sur les tâches d'entreprise courantes comme les questions-réponses sur documents, la classification et la rédaction. Ce domaine évolue vite, avec des sorties significatives tous les quelques mois, donc validez tout choix précis sur vos propres cas de test avant de vous engager.
Quand est-il financièrement plus sensé de rester sur une API facturée au token plutôt que d'auto-héberger ?
Quand le volume est faible ou imprévisible, typiquement quelques milliers de requêtes par mois plutôt que des millions, et que les données ne sont ni réglementées ni contractuellement sensibles. À cette échelle, un serveur GPU dédié ou une instance de cloud privé coûte généralement plus cher à acheter, exploiter et maintenir que la facture d'API qu'il remplacerait.
Quelle est l'erreur la plus fréquente des PME qui exploitent leur propre infrastructure d'IA ?
La traiter comme un achat de matériel ponctuel plutôt que comme une responsabilité d'ingénierie continue. Les équipes dimensionnent un GPU, déploient un modèle et crient victoire, puis regardent la qualité du retrieval se dégrader sur les vrais documents, ou sautent l'évaluation d'une mise à jour de modèle qui change discrètement le comportement en production. Un déficit de compétences récurrent fait sous-performer la plupart des projets d'IA auto-hébergée, bien plus souvent que le coût d'investissement.