Quand une ETI industrielle coupe le cordon avec CUDA : le pari ROCm comme acte de souveraineté

# Quand une ETI industrielle coupe le cordon avec CUDA : le pari ROCm comme acte de souveraineté

Il y a encore dix-huit mois, la question ne se posait même pas. Vouloir entraîner ou déployer un modèle d'IA dans une PME ou une ETI européenne signifiait, dans l'immense majorité des cas, accepter une dépendance implicite : CUDA, l'écosystème propriétaire de Nvidia, et par extension les couches logicielles, les certifications, les formats de modèles et les contrats qui vont avec. Personne ne le formulait clairement. C'était juste « comme ça que ça marchait ».

Ce consensus tacite commence à se fissurer. Et le terrain le confirme.

Une ETI industrielle qui voulait reprendre la main

Une ETI industrielle de 800 salariés, active dans la fabrication de composants mécaniques de précision pour le secteur aéronautique, a entamé en 2025 un chantier qu'elle qualifie elle-même, en interne, de « décolonisation de l'infrastructure IA ». Le terme est fort. Il est assumé.

Le contexte : l'entreprise avait déployé, deux ans plus tôt, une première brique d'IA pour la détection d'anomalies sur ses lignes de contrôle qualité. Un projet pilote solide, des résultats probants, une équipe IT de taille modeste mais compétente. Problème : toute la chaîne reposait sur des GPU Nvidia, des drivers propriétaires, et une dépendance croissante à des services cloud américains pour les phases d'entraînement. Le DSI de l'entreprise résume la situation avec une franchise que j'apprécie : *« On avait construit quelque chose qui marchait, mais dont on ne maîtrisait aucune brique critique. Le jour où Nvidia change sa politique de licence, ou où les coûts cloud explosent, on est coincés. »*

La décision de tester une alternative s'est imposée moins par idéologie que par pragmatisme. La souveraineté, dans ce cas précis, n'est pas un slogan : c'est une gestion du risque fournisseur.

ROCm et Hyperloom : de quoi parle-t-on concrètement ?

ROCm — Radeon Open Compute — est la plateforme open source d'AMD pour le calcul GPU. Elle existe depuis plusieurs années, mais elle souffrait d'une réputation de parent pauvre : moins de compatibilité, moins de bibliothèques optimisées, moins de documentation. Ce retard structurel s'est significativement réduit. En 2026, ROCm supporte nativement les principaux frameworks d'IA, et les GPU AMD de dernière génération rivalisent sérieusement sur les charges d'inférence et d'entraînement léger.

Hyperloom, de son côté, est un orchestrateur de charges IA distribué, né dans l'écosystème européen open source, qui s'est imposé comme une alternative crédible aux solutions d'orchestration américaines dominantes. Sa force : une compatibilité native avec ROCm, une architecture pensée pour fonctionner sur des infrastructures hybrides — y compris on-premise — et une gouvernance qui ne dépend pas d'un acteur californien.

L'association des deux forme quelque chose d'inédit pour une ETI : une chaîne IA de bout en bout, depuis le matériel jusqu'à l'orchestration, qui ne passe ni par les brevets Nvidia ni par les conditions générales d'un hyperscaler américain.

Ce que ça change concrètement pour les équipes IT

Soyons honnêtes : la migration n'a pas été indolore. L'équipe IT de l'ETI — quatre personnes côté infrastructure, deux profils data/ML — a passé plusieurs semaines à requalifier ses environnements. Les drivers, les dépendances Python, certains scripts d'entraînement optimisés pour CUDA ont dû être adaptés. Il faut le dire clairement : ROCm n'est pas un substitut plug-and-play. Il demande un investissement initial réel.

Mais voilà ce que personne ne dit assez : une fois cet investissement consenti, la posture de l'équipe IT change fondamentalement. Le DSI de l'ETI l'exprime ainsi : *« Avant, quand quelque chose ne marchait pas, on attendait qu'un ticket soit traité quelque part dans un support américain. Maintenant, on lit le code. On comprend ce qui se passe. On peut intervenir. »*

C'est là l'enjeu profond, et je pense qu'il est souvent sous-estimé dans les discussions sur la souveraineté numérique : la maîtrise du SI ne se décrète pas, elle se construit par la compréhension des outils qu'on utilise. Une dépendance à une boîte noire propriétaire, même performante, est une abdication de compétence sur le long terme. ROCm, parce qu'il est open source et auditable, remet l'équipe dans une posture d'acteur plutôt que de consommateur.

Sur le plan opérationnel, les gains sont tangibles. La capacité à déployer des charges d'inférence en local, sans appel systématique à un service cloud externe, a réduit les latences sur la chaîne de contrôle qualité. Les données de production — sensibles, couvertes par des engagements contractuels vis-à-vis des clients aéronautiques — ne quittent plus le périmètre de l'entreprise. C'était une exigence non négociable que l'ancienne architecture rendait difficile à tenir.

Hyperloom a, de son côté, simplifié la gestion des files de jobs. L'équipe peut prioriser les charges, monitorer la consommation GPU, et programmer les entraînements périodiques sans dépendre d'une interface cloud tierce. Ce n'est pas spectaculaire. C'est exactement ce dont une équipe IT de taille humaine a besoin : de la lisibilité et du contrôle, sans sur-ingénierie.

Le vrai signal pour les DSI européens

Je veux être direct sur ce que cette expérience révèle, parce que je pense que le secteur a tendance à noyer le sujet sous des considérations techniques.

Le vrai enjeu n'est pas ROCm contre CUDA. C'est la question de savoir si les DSI et CTO d'ETI européennes sont prêts à considérer que la dépendance à un écosystème propriétaire américain est un risque stratégique — et à le traiter comme tel, avec les ressources et la patience que ça requiert.

Pendant des années, l'argument de la performance a suffi à clore le débat. CUDA était plus rapide, mieux documenté, plus supporté. C'était vrai. Ça l'est de moins en moins. L'écart s'est réduit sur les cas d'usage courants des ETI — inférence, détection d'anomalies, traitement d'images industrielles. Ce n'est pas moi qui le dis : c'est l'expérience terrain de cette ETI, et d'autres que je commence à croiser.

Il faut aussi nommer ce que fait AMD avec ROCm : une entreprise américaine qui publie une plateforme open source, ce n'est pas de l'altruisme. C'est une stratégie de marché pour attaquer Nvidia. Les entreprises européennes seraient naïves d'y voir une déclaration d'amour à la souveraineté numérique. Mais elles seraient tout aussi naïves de refuser un levier d'émancipation sous prétexte qu'il vient de l'autre côté de l'Atlantique. L'open source auditable, même s'il a une origine américaine, reste un outil que l'on peut reprendre, forker, adapter — c'est une différence de nature avec une solution propriétaire verrouillée.

La combinaison ROCm + un orchestrateur à gouvernance européenne comme Hyperloom crée quelque chose d'intéressant : une chaîne où la couche critique — l'orchestration, la politique de données, les règles métier — reste sous contrôle européen, même si le matériel et certaines bibliothèques bas-niveau ont une origine américaine. C'est imparfait. C'est réaliste.

Ce que j'en retiens pour les équipes IT

La leçon de terrain que je tire de cette ETI industrielle n'est pas technique. Elle est organisationnelle et culturelle.

Décider de migrer vers un écosystème moins dominant, c'est accepter une phase de friction. Il faut du temps, de la formation, une tolérance au tâtonnement. C'est difficile à vendre en interne quand les tableaux de bord de performance restent corrects avec l'outillage en place. Le DSI de cette ETI a eu la chance d'avoir une direction générale qui comprend la gestion du risque fournisseur — parce que dans l'industrie aéronautique, la dépendance à un fournisseur unique, on sait ce que ça coûte quand ça se passe mal.

Il faut que les DSI et RSSI européens se saisissent de ce langage-là. Pas « souveraineté numérique » comme un étendard idéologique, mais « diversification des dépendances critiques » comme une exigence de résilience. C'est un argument que les directions générales comprennent. Et c'est exactement ce que cette migration incarne.

Le cordon avec CUDA n'est pas coupé pour toujours, ni définitivement. Mais il a été sectionné le temps d'un projet, d'une ligne de production, d'une équipe. C'est comme ça que les alternatives deviennent crédibles : pas par proclamation, mais par accumulation d'expériences qui prouvent que c'est faisable.