7 Min. de lecture

L’intelligence artificielle devient pour les entreprises une question d’infrastructure stratégique. Dans l’échange avec Alexander Hendorf, consultant en IA et expert Open Source, un constat s’impose : qui veut maîtriser l’IA doit être en mesure de comprendre, d’exploiter et de contrôler ce qui se passe dans son propre système. L’Open Source n’est alors pas une option secondaire, mais une condition sine qua non pour le contrôle, la capacité opérationnelle et la compétitivité à long terme.

Articles connexes :Le Platform Engineering n’est plus un projet DevEx  /  SAP Sovereign Cloud France

Le paquet européen mise sur l’Open Source, le goulot d’étranglement se trouve ailleurs

Le 3 juin 2026, la Commission européenne a présenté son European Tech Sovereignty Package : un ensemble comprenant le Chips Act 2.0, un Cloud and AI Development Act et une stratégie dédiée à l’Open Source. Le Cloud and AI Development Act prévu doit établir des niveaux de souveraineté gradués pour les charges de travail sensibles et développer la capacité européenne des centres de données. La stratégie Open Source considère explicitement les logiciels ouverts comme un levier pour réduire la dépendance envers les pays tiers dans les domaines du cloud, de l’IA et de la cybersécurité.

Pour Hendorf, la direction est bonne, mais le focus reste incomplet. La capacité seule ne crée pas de contrôle. L’essentiel est de savoir si les entreprises et les administrations peuvent comprendre, exploiter et auditer les systèmes qui tournent sur cette infrastructure.

L’autonomie en IA commence par l’infrastructure

Qu’est-ce que l’autonomie en IA ? L’autonomie en IA décrit la capacité d’une entreprise à choisir, intégrer, exploiter et vérifier elle-même des systèmes d’IA. Cela inclut le contrôle des flux de données, des modèles, de l’infrastructure, de la qualité, de la sécurité et des chemins d’échange. Ce qui compte, ce n’est pas le nom du modèle, mais sa capacité opérationnelle.

Beaucoup d’entreprises débattent actuellement de l’autonomie en IA, des modèles européens comme Mistral ou de l’utilisation du logiciel libre. Il ne s’agit plus seulement de quelques applications ou chatbots. L’IA s’inscrit désormais profondément dans les processus métier, les plateformes de données et les architectures cloud : de l’analyse des contrats à la communication client en passant par la recherche interne de connaissances.

Même lors de conférences sur l’IA comme la PyCon DE et PyData, ce changement est visible. Ces événements portent désormais moins sur les modèles et les frameworks, mais davantage sur des sujets tels que les agents d’IA, les standards API, les architectures de données et l’ingénierie logicielle. C’est pourquoi la question se déplace de la sélection du modèle vers la capacité opérationnelle.

Le choix entre cloud et on-premise est la mauvaise question

Le débat autour de l’autonomie en IA est souvent mené de manière trop unilatérale. On a souvent l’impression que les entreprises doivent nécessairement choisir entre cloud et on-premise. Selon Hendorf, cette vision est trop réductrice.

Il est plutôt essentiel de savoir si les entreprises comprennent et maîtrisent leur infrastructure, indépendamment de son emplacement. Celui qui s’appuie uniquement sur des hyperscalers et des fournisseurs SaaS risque rapidement de tomber dans différentes dépendances : les versions de modèles changent sans préavis, les prix et quotas sont ajustés unilatéralement, les flux de données atterrissent dans des régions non approuvées par les équipes conformité. En revanche, un déploiement local n’a de sens que si les compétences nécessaires existent en interne.

« Le logiciel n’est pas l’actif, il est disponible partout. Même les hyperscalers utilisent du logiciel libre et le promeuvent activement », explique Hendorf. « L’actif, c’est la capacité opérationnelle : comprendre un système, le mettre en place soi-même et, si besoin, passer d’un cloud à une propre infrastructure matérielle. C’est exactement ce skillset qui manque chez beaucoup. »

Ce que cette capacité opérationnelle signifie concrètement peut se mesurer à un terme qui est déjà standard dans les cercles techniques, mais rarement mentionné en direction générale : la Harness. Il s’agit d’un environnement de test et d’évaluation propre à l’entreprise, où chaque modèle d’IA est systématiquement testé contre ses propres cas d’application, des échantillons de données et des critères de qualité avant d’être mis en production.

« La Harness est véritablement l’actif », affirme Hendorf. « C’est le garde-fou pour les changements de modèles et les mises à jour. Sans elle, tout changement devient un vol au noir. On découvre seulement plusieurs semaines plus tard en exploitation si le nouveau modèle fait encore exactement ce que le précédent faisait. Avec elle, le changement devient une décision technique routinière. »

Cette lacune représente l’une des plus grandes faiblesses des entreprises souhaitant changer de fournisseur ou mettre à jour un modèle. Celui qui n’a pas sa propre Harness doit se fier aux annonces des notes de version et y croire pendant l’exploitation en cours.

Open Source change la donne

Les modèles, les frameworks et les composants d’infrastructure sont aujourd’hui aussi largement disponibles qu’ils ne l’ont jamais été : des modèles linguistiques ouverts comme Llama ou Mistral, en passant par des serveurs d’inférence tels que vLLM et Ollama, jusqu’aux bases de données vectorielles pour la recherche interne du savoir. Cela déplace ainsi la débats sur l’intelligence artificielle loin de la simple question de qui dispose du modèle le plus performant. Ce qui devient désormais plus important, c’est de savoir qui peut comprendre, adapter et gérer fiablement les systèmes d’intelligence artificielle.

La distance par rapport à la pointe propriétaires se réduit. Hendorf fait référence aux estimations issues du milieu PyCon, selon lesquelles les modèles commerciaux sont généralement seulement quelques mois, et non plusieurs années, devant les alternatives ouvertes. Pour les entreprises, cela représente un changement pertinent : elles peuvent de plus en plus configurer, exploiter localement, intégrer dans leurs processus et contrôler davantage les systèmes d’intelligence artificielle. Cette nouvelle liberté accroît cependant également la responsabilité au sein de leur propre organisation.

Dans la mesure où l’open source n’élimine pas automatiquement la dépendance vis-à-vis des fournisseurs individuels, il transfère les exigences. Qui souhaite utiliser une intelligence artificielle ouverte doit avoir des compétences techniques, des décisions architecturales claires, une gouvernance et la capacité à évaluer de manière réaliste la qualité, la sécurité et les coûts d’exploitation.

Cela met en lumière une question qui, dans le brouhaha autour des modèles européens ou américains, est souvent occultée : selon quels critères les entreprises devraient-elles choisir un système d’intelligence artificielle ? Ce qui compte moins encore est la provenance d’un modèle, mais plutôt s’il convient au cas concret d’application, à la base de données existante, aux exigences réglementaires et à sa faisabilité d’exploitation.

« La décision sur quel modèle disponible aujourd’hui une entreprise utilise dépend non pas de son origine, mais de son application », explique Hendorf. « Les modèles chinois, comme ceux de DeepSeek ou Qwen, appartiennent techniquement à la pointe, sont ouverts et accessibles, et sont souvent comparables ou supérieurs aux modèles open-source occidentaux. Le fait que leurs données d’entraînement soient politiquement filtrées n’est pas un critère décisif pour la plupart des cas d’utilisation d’entreprise, comme l’analyse de contrats, la recherche de connaissances ou la classification. Le biais existe dans chaque modèle. La question pertinente n’est pas d’où il vient, mais si on peut le maîtriser dans son application spécifique. »

Pourquoi les solutions plus petites sont souvent plus pertinentes

Comme le montre un exemple pratique dans le domaine financier, cette question est devenue extrêmement pertinente. Un gestionnaire d’actifs souhaitait entraîner ses propres modèles d’intelligence artificielle et pensait initialement à une solution cloud. Toutefois, dans un environnement hautement réglementé, les processus de gouvernance et de conformité auraient pris entre 12 et 24 mois. Pendant cette période, de nombreux projets sont reportés avant même d’être mis en production.

Après analyse du cas d’utilisation réel, la décision a pris une autre direction : au lieu d’utiliser un grand modèle généraliste, une solution nettement plus petite a été développée, basée sur un serveur interne et deux GPU de consommation Nvidia dans un réseau sécurisé. Selon Hendorf et son équipe, elle a été mise en production en quatre semaines.

L’effet : la solution globale a coûté moins de six mois d’exploitation cloud. En même temps, les employés ont pu immédiatement utiliser le système, sans attendre des autorisations longues et lourdes.

Pour Hendorf, cet exemple illustre un problème fondamental de nombreux projets d’intelligence artificielle. Les entreprises s’orientent souvent vers une maximisation de l’échelle, alors que leurs besoins sont bien plus spécialisés : « N’importe quel cas d’utilisation n’a pas besoin d’un Porsche, parfois un vélo à pédales suffit. » Les modèles plus petits, avec quelques milliards de paramètres, peuvent être plus efficaces, moins coûteux et plus facilement contrôlables pour des tâches clairement définies que les grands systèmes universels. Et ils s’exécutent sur de l’hardware que l’entreprise possède elle-même.

Les agents d’IA accentuent la pression sur l’organisation

Avec l’émergence des agents d’IA, cette tendance s’accentue davantage. Les agents accèdent aux données, utilisent des API et automatisent les processus. Pour cela, ils ont besoin d’environnements techniques structurés.

Les solutions en silo développées au fil du temps, les interfaces mal documentées et les paysages d’outils complexes deviennent ainsi de plus en plus problématiques. Selon Hendorf, les agents d’IA fonctionnent nettement mieux avec des API standardisées et des structures de données cohérentes. De nouveaux standards ouverts comme le Model Context Protocol exigent que les systèmes sous-jacents soient proprement documentés et accessibles. Lorsque cela fait défaut, les agents n’échouent pas à cause du modèle, mais à cause de l’architecture interne.

Cela contraint les entreprises à réévaluer leur infrastructure. L’Open Source peut aider, car les systèmes deviennent plus transparents et plus flexibles. Cependant, sans une architecture propre et un bon Software Engineering, une nouvelle complexité apparaît rapidement.

La sécurité ne va pas de soi

Sur le plan de la sécurité et de la protection des données, Hendorf relève également de nombreux malentendus. L’Open Source ne serait pas automatiquement sûr. Quiconque télécharge un modèle depuis un hub en ligne sans en vérifier la provenance importe la même logique de risque que pour toute autre chaîne d’approvisionnement logicielle. Dans le même temps, une infrastructure locale n’est pas intrinsèquement plus risquée que des environnements Cloud complexes aux flux de données difficiles à tracer.

Pour les données sensibles en particulier, les réseaux internes sécurisés peuvent présenter des avantages. Le contrôle d’accès, la gouvernance et l’architecture technique restent toutefois décisifs. Cela soulève aussi la question de savoir qui, en cas de doute, sera capable de retracer de manière forensique les données qu’un modèle a traitées, et à quel moment.

L’IA transforme ainsi le rôle des équipes IT et de sécurité. Elles doivent permettre l’innovation tout en garantissant que les entreprises conservent le contrôle sur leurs données, leurs modèles et leurs processus.

L’infrastructure devient un avantage concurrentiel

Le débat sur l’IA Open Source est donc bien plus qu’une simple question de modèle. Les entreprises doivent décider à quel point elles souhaitent être dépendantes des plateformes externes à l’avenir et quelles connaissances techniques et organisationnelles elles doivent développer en interne.

Les plateformes Cloud et les modèles propriétaires continueront de jouer un rôle important. Parallèlement, l’importance de la capacité opérationnelle propre ne cesse de croître. C’est précisément là que Hendorf voit le véritable fondement de la souveraineté numérique.

La situation réglementaire vient par ailleurs exacerber ce débat. L’EU AI Act classe certaines applications d’IA, par exemple dans les ressources humaines, l’octroi de crédits ou les infrastructures critiques, comme étant à haut risque et exige des flux de données traçables, des décisions de modèles documentées et des processus d’exploitation auditables.

Autrement dit : quiconque souhaite utiliser l’IA de manière stratégique à long terme a besoin non seulement d’accéder aux modèles, mais aussi de contrôler l’infrastructure sous-jacente.

Quiconque est incapable de répondre à ces questions en l’espace d’une journée n’a pas un problème de modèle, mais un problème d’architecture. C’est là que commence le véritable travail vers une IA souveraine.

Foire aux questions

Qu’est-ce qui distingue l’IA souveraine de l’IA cloud classique ?

L’IA souveraine signifie qu’une entreprise peut contrôler ses modèles, ses flux de données, la qualité et les opérations. L’emplacement à lui seul ne suffit pas à trancher. Une solution cloud peut également être souveraine si l’architecture, la gouvernance et les chemins de migration sont maîtrisés.

Pourquoi un harness dédié est-il si important ?

Un harness teste les modèles par rapport aux cas d’usage et aux critères de qualité propres à l’entreprise. Sans cet environnement de test, tout changement de modèle reste risqué, car les écarts ne deviennent souvent visibles qu’en environnement de production.

Pourquoi des configurations on-premise plus petites suffisent-elles souvent ?

De nombreux cas d’usage en entreprise n’ont pas besoin d’un grand modèle générique. Des modèles plus petits et spécialisés peuvent s’avérer moins coûteux, plus rapides et plus faciles à contrôler pour des tâches clairement délimitées.

Source de l’image : générée par IA (mai 2026), certificat C2PA intégré à l’image