« Le procès OpenAI nous a offert le meilleur argument que j'aie jamais eu face à ma direction »

# « Le procès OpenAI nous a offert le meilleur argument que j'aie jamais eu face à ma direction »

*En 2026, l'affaire judiciaire impliquant OpenAI dépasse le cadre américain. Pour les DSI européens engagés sur des projets IA, elle agit comme un révélateur brutal : dépendre d'une IA propriétaire américaine, c'est s'exposer à des risques que ni les contrats ni les architectures ne neutralisent vraiment. Un directeur des systèmes d'information d'une ETI industrielle française, engagé depuis deux ans dans une migration partielle vers des modèles ouverts, nous livre son analyse sans détour.*

RiffLab : Quand vous avez suivi l'évolution du procès OpenAI, quelle a été votre première réaction en tant que DSI ?

Franchement ? Un mélange de soulagement et d'irritation. Soulagement parce que ce qui se passe devant les tribunaux américains confirme exactement ce que je répétais en interne depuis dix-huit mois sans être vraiment entendu : on ne peut pas construire un actif stratégique sur une infrastructure dont la gouvernance nous échappe totalement. Irritation parce qu'il a fallu en arriver là — une procédure judiciaire outre-Atlantique, des témoignages sous serment sur les dérives internes d'une organisation américaine — pour que la direction générale daigne considérer le sujet comme sérieux.

Ce procès expose quelque chose de structurel : OpenAI n'est pas une entreprise comme les autres. Sa structure de gouvernance hybride, les tensions entre sa mission déclarée et ses intérêts commerciaux, l'influence de ses investisseurs sur ses orientations produit — tout ça, ce n'est pas un détail. C'est le cœur du problème pour nous, utilisateurs européens qui n'avons aucun levier sur ces décisions.

RiffLab : Concrètement, quels verrouillages contractuels ce type de dépendance crée-t-il pour une ETI comme la vôtre ?

Il y en a plusieurs niveaux, et ils se cumulent. Le premier, c'est le verrouillage sur les conditions d'utilisation. Avec un fournisseur d'IA propriétaire américain, vous signez des CGU qui peuvent être modifiées unilatéralement. On l'a vu se produire : des clauses sur la rétention des données d'entraînement, sur les droits d'audit, sur la sous-traitance vers des infrastructures tiers — tout ça peut évoluer sans que vous ayez votre mot à dire.

Le deuxième niveau, c'est le verrouillage fonctionnel. Quand vos équipes métier ont passé un an à affiner des prompts, à construire des workflows autour d'une API spécifique, à former leurs utilisateurs sur une interface propriétaire — le coût de sortie devient astronomique. Pas en argent, en temps et en réapprentissage organisationnel. C'est exactement ce que ces acteurs espèrent.

Et le troisième, celui qu'on oublie souvent : le verrouillage réglementaire inversé. Si demain le régulateur européen — que ce soit via l'AI Act ou une jurisprudence nationale — impose des exigences de transparence sur les modèles utilisés en contexte sensible, vous vous retrouvez coincé entre votre obligation légale et l'impossibilité technique d'auditer un modèle fermé. Vous êtes en infraction potentielle à cause d'une décision prise à San Francisco.

RiffLab : Le procès a mis en lumière des tensions internes chez OpenAI sur la direction stratégique de l'entreprise. En quoi est-ce un risque opérationnel direct pour vous ?

C'est précisément là que ça devient concret pour un DSI. Quand vous intégrez profondément un outil dans votre SI — et par profondément, j'entends au niveau des processus RH, de la relation client, de la chaîne logistique — vous pariez implicitement sur la continuité du service et la stabilité des choix techniques du fournisseur.

Or ce que le procès révèle, c'est qu'OpenAI est une organisation traversée par des conflits d'intérêts majeurs entre ses différentes parties prenantes. Les priorités peuvent pivoter brutalement selon qui prend le dessus en interne. On l'a déjà vu sur les questions de sécurité, de vitesse de déploiement, de monétisation. Pour moi, ça se traduit en risque de continuité d'activité. Que se passe-t-il si une décision de gouvernance interne entraîne une modification majeure du modèle que j'utilise en production ? Je n'ai aucun mécanisme contractuel pour me protéger contre ça. Aucun droit d'opposition. Aucun préavis garanti utilisable.

Avec un modèle open source déployé sur mon infrastructure, ce scénario n'existe pas. Le modèle est là, il est figé dans la version que j'ai choisie, et personne ne peut le modifier à distance.

RiffLab : Vous avez commencé une migration partielle. Qu'est-ce qui vous a fait franchir le pas, et qu'est-ce qui freine encore ?

Le déclencheur a été un incident assez banal : un changement de comportement du modèle d'un appel API à l'autre, sans notification préalable, qui a cassé une chaîne de traitement automatisée qu'on avait en production. Rien de dramatique, mais ça nous a coûté une journée de travail et ça a mis en évidence l'absence totale de versioning stable sur les APIs propriétaires.

À partir de là, j'ai obtenu le budget pour tester une approche hybride : des modèles ouverts, hébergés sur une infrastructure que nous contrôlons, pour les usages sensibles ou critiques — traitement de documents internes, assistance aux équipes juridiques, analyse de données fournisseurs. Et on maintient une exposition réduite aux services propriétaires pour des usages moins stratégiques.

Ce qui freine encore ? L'honnêteté oblige à dire que la performance brute sur certaines tâches complexes reste un écart réel. Il se réduit vite, mais il existe. Et la maturité des outils d'orchestration autour des modèles ouverts est encore inégale. Ce n'est pas insurmontable, mais ça demande des compétences en interne qu'on est en train de construire.

RiffLab : L'écosystème européen est-il en mesure de répondre sérieusement à ce besoin, ou est-on encore dans le vœu pieux ?

On est dans une phase de transition réelle, pas dans le vœu pieux — mais il faut être honnête sur ce que ça implique. Il existe aujourd'hui des modèles open source de qualité sérieuse, entraînés ou affinés en Europe, avec des licences qui permettent un déploiement sur site. L'offre existe. Le défi n'est plus là.

Le défi, c'est l'accompagnement. La plupart des ETI comme la nôtre n'ont pas les équipes pour déployer, optimiser et maintenir ces modèles seules. Il faut des intégrateurs qui connaissent vraiment le sujet — pas des revendeurs de solutions américaines avec un vernis open source. Et là, l'écosystème européen se construit, mais il manque encore de masse critique et de standardisation des pratiques.

Ce que j'attends du niveau politique et réglementaire européen, c'est moins des subventions que des signaux clairs sur les exigences à venir. Si l'AI Act commence à imposer concrètement des obligations de transparence sur les systèmes IA utilisés dans des secteurs critiques, ça va accélérer les migrations bien plus vite que n'importe quel plan de soutien à l'innovation.

RiffLab : Quel conseil donneriez-vous à un DSI qui commence tout juste à se poser ces questions ?

Ne commencez pas par la technologie. Commencez par cartographier votre exposition. Listez tous les processus de votre SI qui dépendent aujourd'hui, directement ou indirectement, d'un modèle IA propriétaire américain. Qualifiez leur criticité. Posez-vous la question : si ce service disparaît demain matin, ou modifie ses conditions en profondeur, quel est mon délai de réaction et quel est mon plan B ?

Dans la majorité des cas, vous découvrirez que vous n'avez pas de plan B. C'est le vrai diagnostic. Le procès OpenAI n'est qu'un symptôme visible d'une réalité plus profonde : nous avons intégré des dépendances critiques sans jamais négocier les garde-fous correspondants. La bonne nouvelle, c'est que contrairement à ce qu'on vit avec certaines dépendances cloud depuis quinze ans, il est encore temps d'agir avant que le verrouillage soit total. La fenêtre existe. Elle ne restera pas ouverte indéfiniment.