« On peut industrialiser l'IA sans signer un chèque en blanc à San Francisco »

# « On peut industrialiser l'IA sans signer un chèque en blanc à San Francisco »

*En 2026, les modèles d'IA ne sont plus réservés aux laboratoires de recherche. Ils tournent en production dans les entreprises. Mais derrière cette industrialisation se cache une question que peu de DSI osent poser à voix haute : à qui appartient vraiment l'infrastructure qui fait tourner ces modèles ? Rencontre avec un DSI d'une ETI industrielle française, qui a choisi de répondre à cette question avant qu'elle ne se pose dans un contrat.*

RiffLab Media : On entend beaucoup parler d'industrialisation de l'IA en 2026. Mais concrètement, qu'est-ce que ça veut dire pour un DSI de PME ou d'ETI ?

Ça veut dire que l'IA n'est plus un projet pilote qu'on montre en démo au comité de direction. Elle est dans les processus. Elle traite des documents contractuels, elle assiste les équipes techniques, elle analyse des flux de données métier en temps réel. Industrialiser, c'est faire passer l'IA du statut d'expérimentation à celui de composant du système d'information — le SI, c'est-à-dire l'ensemble des outils et infrastructures numériques de l'entreprise.

Et c'est là que le sujet devient stratégique. Parce que quand on industrialise via un acteur américain, on ne choisit pas juste un outil. On signe pour une dépendance structurelle. Les données qui alimentent les modèles transitent par leurs serveurs. Les contrats imposent leurs juridictions. Et si les tarifs changent — ce qui arrive — vous renegociez en position de faiblesse.

Vous parlez de dépendance structurelle. Pouvez-vous expliquer ce que ça recouvre techniquement pour quelqu'un qui découvrirait le sujet ?

Il y a deux niveaux de verrouillage, et il faut les distinguer.

Le premier, c'est le verrouillage technique. Quand vous intégrez un modèle d'IA via une API — une interface de programmation qui permet à vos logiciels de dialoguer avec un service externe — vous construisez toute votre chaîne autour du format, des conventions et des contraintes de cette API. Si l'acteur américain modifie son API, vous devez vous adapter. Si vous voulez en changer, vous devez tout reconstruire.

Le second, c'est le verrouillage contractuel. Les conditions d'utilisation des grands acteurs US stipulent souvent qu'ils peuvent utiliser vos données pour améliorer leurs modèles, sauf opt-out explicite — et encore, pas toujours disponible sur les offres d'entrée de gamme. Les clauses de résiliation sont rarement à votre avantage. Et le droit applicable est généralement américain, ce qui crée une asymétrie réelle en cas de litige.

Quand on combine les deux, on obtient une situation où changer de fournisseur devient techniquement coûteux et contractuellement risqué. C'est ça, la dépendance structurelle.

Qu'est-ce que l'open-source change concrètement à cette équation ?

L'open-source — le fait que le code source d'un logiciel soit librement consultable, modifiable et redistribuable — desserre le premier niveau de verrouillage. Vous pouvez déployer le modèle sur votre propre infrastructure. Vous n'avez plus besoin d'envoyer vos données à l'extérieur pour faire tourner l'IA. Le modèle est chez vous, sur des serveurs que vous contrôlez ou que vous louez à un hébergeur soumis au droit européen.

Mais attention — et c'est un point que beaucoup ratent — l'open-source ne règle pas tout. Une licence open-source peut autoriser l'usage commercial mais interdire certaines modifications. Certains modèles publiés sous licence ouverte restent soumis à des conditions d'usage restrictives. Il faut lire les licences. Ce n'est pas glamour, mais c'est fondamental.

Ce qui change vraiment, c'est la capacité à auditer. Avec un modèle open-source, votre équipe de sécurité — ou un prestataire européen de confiance — peut inspecter le code. Vous savez ce que vous déployez. C'est une exigence de base quand on parle de données métier sensibles.

Vous avez évalué des solutions open-source européennes. Qu'est-ce qui distingue les projets européens des projets américains sur ce terrain ?

Plusieurs choses, qui ne sont pas toutes techniques.

D'abord, la conformité réglementaire par conception. Les acteurs européens — je pense notamment à ce que fait LlamaIndex Europe ou à des initiatives portées dans le cadre du GAIA-X, le projet d'infrastructure de données européenne — intègrent les exigences du RGPD dès la conception. Le RGPD, c'est le Règlement Général sur la Protection des Données, qui encadre le traitement des données personnelles en Europe. Ce n'est pas une couche ajoutée après coup pour cocher une case. C'est structurant.

Ensuite, l'ancrage juridique. Quand je contracte avec un acteur basé en Allemagne ou en France, le contrat relève du droit européen. En cas de problème, je ne me retrouve pas à naviguer dans un système juridique étranger avec des ressources que je n'ai pas.

Enfin — et ça compte — la proximité. Pas la proximité géographique pour le romantisme, mais la proximité opérationnelle. Quand j'ai un problème critique en production à 2h du matin, le fuseau horaire et la langue de support, ça compte.

Concrètement, quels types de cas d'usage avez-vous industrialisés avec des briques open-source européennes ?

Je vais vous en citer deux, sans entrer dans les détails techniques de notre stack — ce n'est pas le sujet.

Le premier : l'analyse automatisée de documents contractuels. Nos équipes juridiques et achats traitent un volume important de contrats fournisseurs. On a déployé un modèle de langage — un LLM, pour Large Language Model, un modèle d'IA entraîné sur de grandes quantités de texte — en local, sur notre infrastructure hébergée chez un acteur européen certifié. Le modèle extrait les clauses à risque, les dates clés, les engagements de niveau de service. Tout reste dans notre périmètre. Aucune donnée contractuelle ne sort.

Le second : l'assistance aux techniciens de maintenance. Nos techniciens terrain posent des questions en langage naturel à un assistant IA qui connaît notre documentation technique. Là encore, le modèle tourne en interne. La documentation métier ne quitte pas notre SI.

Dans les deux cas, la clé n'était pas de trouver le modèle le plus puissant du marché. C'était de trouver le modèle suffisamment bon, qu'on pouvait contrôler, auditer et héberger nous-mêmes.

Quelles sont les limites réelles de cette approche ? Il ne faut pas vendre du rêve à nos lecteurs.

Non, clairement. Il y a des limites sérieuses.

La première, c'est la charge opérationnelle. Déployer et maintenir un modèle open-source en production, ça demande des compétences internes ou un prestataire de confiance. Ce n'est pas plug-and-play. Si votre DSI n'a pas de profils capables de gérer ça, il faut les former ou les recruter — et ce marché est tendu.

La seconde, c'est la performance sur certaines tâches complexes. Sur des cas d'usage très exigeants en raisonnement, les meilleurs modèles américains gardent une avance. C'est une réalité. Mais pour la majorité des usages métier d'une PME ou d'une ETI, des modèles open-source bien calibrés suffisent largement.

La troisième — et c'est peut-être la plus importante — c'est la gouvernance des données d'entraînement. Quand vous commencez à fine-tuner un modèle — c'est-à-dire à l'adapter à votre domaine métier avec vos propres données — vous devez vous assurer que ce processus est lui-même sécurisé et traçable. Ce n'est pas trivial.

Un dernier mot pour les DSI qui hésitent encore à franchir le pas ?

Je leur dirais ceci : la question n'est plus « est-ce que l'open-source est mature ? ». En 2026, la réponse est oui, sur un périmètre large et croissant.

La vraie question, c'est : dans cinq ans, quand votre IA sera au cœur de vos processus critiques, qui aura la main sur l'interrupteur ? Vous — ou un acteur américain dont les priorités, les prix et les politiques peuvent changer du jour au lendemain, sans que vous ayez votre mot à dire ?

L'indépendance numérique, ça se construit avant d'en avoir besoin. Pas après.

*Cette interview est fictive et composite. Elle reflète des problématiques réelles rencontrées par des DSI européens dans le cadre de projets d'industrialisation de l'IA en 2025-2026.*