Le partenariat IBM OpenAI cible les opérations clés, mais le vrai défi reste un déploiement sécurisé
- Martin Chen

- 14 août
- 15 min de lecture
IBM et OpenAI ont annoncé un partenariat stratégique le 13 août, prévoyant de mobiliser des milliers de spécialistes pour des déploiements où l’échec de l’automatisation peut avoir de réelles conséquences. L’accord entre IBM et OpenAI vise la finance, les achats, le service client, les ressources humaines, le développement logiciel et la cybersécurité. Sa promesse centrale ne consiste pas simplement à élargir l’accès aux modèles. Elle porte sur un déploiement maîtrisé au sein des systèmes complexes qui font fonctionner les grandes organisations.
Cette distinction crée la tension au cœur de l’accord. OpenAI travaille déjà avec Accenture, BCG, Capgemini et McKinsey sur l’adoption en entreprise. IBM doit démontrer que sa combinaison de conseil, d’expertise en infrastructure hybride et de contrôles de sécurité produit quelque chose de plus durable qu’un autre vaste programme de formation.
Le partenariat invite également les entreprises à revoir leur manière d’acheter de l’IA. Au lieu de choisir un modèle puis de mettre en place la gouvernance plus tard, les clients recevraient modèles, services d’implémentation, refonte des flux de travail et garde-fous dans le cadre d’une seule relation de prestation. Cela peut réduire la fragmentation, mais aussi accroître la dépendance envers les organisations qui gèrent le déploiement.
Ce que l’accord IBM OpenAI change réellement
IBM et OpenAI font évoluer leur relation, passant d’une collaboration ciblée en cybersécurité à un canal plus large de déploiement en entreprise.
Selon le premier rapport sur le partenariat, IBM prévoit d’intégrer les modèles et produits d’OpenAI à IBM Consulting Advantage. Cette plateforme fournit des outils d’IA, des agents et des ressources réutilisables aux consultants IBM qui accompagnent les clients.
L’intégration prévue inclut GPT-5.6, Codex et ChatGPT Work. GPT-5.6 est la dernière famille de modèles d’OpenAI destinée aux charges de travail professionnelles et de production. Codex prend en charge les tâches d’ingénierie logicielle, tandis que ChatGPT Work offre un environnement dédié au travail de connaissance et à la collaboration.
IBM prévoit également de créer une pratique OpenAI dédiée. Elle comprendra des milliers de consultants et d’ingénieurs formés via l’OpenAI Partner Network, avec des certifications avancées attendues pour les spécialistes participants.
Ces personnes comptent autant que les produits. Un modèle peut immédiatement rédiger du code ou analyser un document. Il ne peut pas déterminer de manière autonome quelles validations d’achats doivent rester sous contrôle humain, ni comment une banque doit documenter une décision automatisée.
L’effort conjoint se concentre sur trois domaines de déploiement. Le premier couvre les opérations métier clés, notamment la finance, les achats, le service client et les ressources humaines. Ces flux de travail traversent souvent plusieurs systèmes et contiennent des données d’entreprise ou personnelles sensibles.
Le deuxième domaine concerne la modernisation des applications et le développement logiciel. IBM prévoit d’associer Codex et ChatGPT Work à son expérience sectorielle et d’ingénierie. L’objectif est d’aider les équipes à comprendre les systèmes existants, à faire évoluer les applications, à examiner le code et à gérer les changements techniques.
Le troisième domaine porte sur la cybersécurité et la gestion des risques liés à l’IA. Ce travail prolonge la participation d’IBM à l’OpenAI Daybreak Cyber Partner Program. Il relie les capacités avancées des modèles aux services de sécurité d’IBM, notamment à son approche de la gestion des risques multi-agents.
L’accord fait donc plus qu’ajouter GPT-5.6 à la boîte à outils d’un consultant. Il établit une voie de commercialisation commune, un groupe d’implémentation formé et une plateforme de prestation partagée pour introduire les produits OpenAI dans des environnements critiques pour l’activité.
IBM n’a pas communiqué les conditions financières, les objectifs contractuels ni les revenus attendus. L’entreprise n’a pas non plus publié le nombre de clients concernés par le partenariat élargi. Ces omissions font de l’annonce une déclaration d’intention, et non la preuve d’une adoption déjà réalisée à grande échelle.
IBM et OpenAI précisent également que les déclarations concernant leurs projets futurs représentent des objectifs susceptibles d’évoluer. Cette formulation est courante dans les annonces d’entreprise, mais elle est importante ici. La pratique dédiée, les certifications, les intégrations et les résultats obtenus chez les clients devront faire l’objet de vérifications distinctes à mesure qu’ils se concrétiseront.
IBM OpenAI vend l’intégration, pas l’accès aux modèles
Le partenariat repose sur un constat simple : l’accès à un modèle performant n’est plus le principal obstacle à l’adoption de l’IA en entreprise.
De nombreuses grandes organisations peuvent déjà accéder à des modèles commerciaux via une API, une marketplace cloud ou une suite de productivité. Leur problème le plus difficile commence une fois cet accès approuvé.
Un système de production utile doit se connecter aux contrôles d’identité, aux bases de données, aux applications internes, aux chaînes de validation et aux journaux d’audit. Il doit respecter les limites de données tout en produisant des résultats que les employés peuvent examiner. Il doit aussi être surveillé lorsque les modèles ou les règles métier évoluent.
Andy Baldwin, vice-président senior d’IBM Consulting, a présenté le défi comme une intégration sécurisée au sein d’environnements et de flux de travail d’entreprise complexes. Cette position explique pourquoi IBM place Consulting Advantage au centre de l’accord.
IBM Consulting Advantage est une plateforme de prestation d’IA utilisée par les consultants de l’entreprise. Elle organise des assistants, des agents, des méthodes et des composants réutilisables que les équipes peuvent appliquer lors de missions clients. IBM affirme que la plateforme a soutenu plus de 150 missions et augmenté la productivité des consultants jusqu’à 50 %.
Ces chiffres proviennent des propres mesures d’IBM et n’établissent pas les retours clients des déploiements OpenAI. Néanmoins, la plateforme fournit au partenariat une couche de prestation opérationnelle. IBM n’a pas besoin d’inventer un nouveau système d’exploitation pour chaque mission.
Le mécanisme envisagé est simple. OpenAI fournit les modèles et les applications. IBM les associe à des processus sectoriels, à l’intégration technique, à la supervision humaine et à des services continus. Des équipes formées adaptent ensuite cet ensemble aux systèmes de chaque client.
Prenons un flux de travail d’achats. Un modèle pourrait comparer des documents fournisseurs, signaler des clauses inhabituelles, rédiger une recommandation et rassembler les éléments justificatifs. Pourtant, le système a toujours besoin de règles d’accès, de seuils d’escalade, d’un suivi des sources et d’un circuit d’approbation final.
Un déploiement dans le service client présente une autre version du même problème. Un agent d’IA peut récupérer des informations de compte et proposer une réponse. Il doit également éviter d’exposer les données d’un autre client, respecter les politiques régionales et transmettre les cas difficiles à un employé.
La modernisation des applications augmente encore les enjeux. Les logiciels existants contiennent souvent des règles métier non documentées, élaborées au fil des décennies. Codex peut aider à examiner les dépendances, expliquer le code, générer des tests et proposer des modifications. IBM doit néanmoins vérifier que ces changements préservent le comportement opérationnel dont dépend un client.
C’est là que le partenariat pourrait devenir précieux. Le modèle prend en charge l’analyse et la génération, tandis que le cadre de prestation contrôle les accès, les preuves, les tests et les escalades. Aucune des deux parties ne suffit seule pour un flux de travail à fortes conséquences.
Pour les travailleurs du savoir, le même schéma s’applique à plus petite échelle. L’IA fournit une assistance plus fiable lorsqu’elle peut utiliser des informations pertinentes sans perdre le contexte des sources. Une base de connaissances IA bien entretenue peut aider les personnes à organiser ce contexte avant que l’automatisation n’atteigne une décision critique.
La proposition IBM OpenAI dépend donc moins d’une victoire sur un benchmark isolé que d’une conception opérationnelle rigoureuse. Les entreprises évalueront si le système combiné accomplit un travail utile sans créer de charges de contrôle inacceptables ni de nouvelles failles de sécurité.
Accenture et d’autres alliances occupent déjà ce marché
IBM entre dans une course à l’implémentation très concurrentielle, où OpenAI a délibérément évité de s’appuyer sur un seul partenaire de conseil.
OpenAI a présenté ses Frontier Alliances en février avec BCG, McKinsey, Accenture et Capgemini. Le programme répartit le travail d’adoption en entreprise entre stratégie, conception du modèle opérationnel, intégration des systèmes, modernisation des données, gestion du changement et support à long terme.
BCG et McKinsey se concentrent fortement sur la stratégie et la refonte organisationnelle. Accenture et Capgemini apportent de grandes organisations de prestation capables de connecter les modèles aux systèmes de production. OpenAI affirme que ces entreprises aident les clients à passer des expérimentations à des capacités déployées à l’échelle de l’entreprise.
Accenture représente le point de pression le plus évident pour IBM. Sa relation élargie avec OpenAI comprend des dizaines de milliers de professionnels utilisant ChatGPT Enterprise. Lors de l’annonce de l’alliance, OpenAI avait décrit ce déploiement comme son plus grand groupe de professionnels formés via les certifications OpenAI.
Le modèle Frontier Alliance offre à OpenAI plusieurs voies d’accès aux grandes entreprises. Il maintient aussi les cabinets de conseil en concurrence pour des budgets de transformation similaires, des talents techniques et l’attention des dirigeants.
IBM ne peut pas remporter cette compétition uniquement grâce à des affirmations sur ses effectifs. Des milliers de spécialistes certifiés peuvent sembler considérables, mais la certification ne démontre pas que ces spécialistes savent repenser un processus de gestion des sinistres ou moderniser en toute sécurité un système de paiement.
La distinction d’IBM réside dans sa présence dans le conseil, les logiciels, l’infrastructure et les opérations d’entreprise de longue date. L’entreprise entretient des relations profondes dans les secteurs bancaire, public, des télécommunications, de la santé et de l’industrie manufacturière. Nombre de ses clients exploitent également des environnements hybrides combinant mainframes, systèmes privés et plusieurs clouds publics.
Cette position pourrait aider IBM à traiter des charges de travail qui ne s’intègrent pas facilement à un seul cloud ou à une seule suite applicative. Elle pourrait également créer des tensions internes. IBM commercialise son propre portefeuille watsonx tout en maintenant des partenariats étendus avec Microsoft, AWS, Google Cloud et d’autres fournisseurs technologiques.
En juin, IBM a annoncé une pratique Google Cloud distincte qui étend Consulting Advantage avec les capacités de Gemini Enterprise. L’entreprise dispose également d’une importante pratique Microsoft et a précédemment fourni des services Azure OpenAI.
Cette posture multi-modèles est utile aux clients qui souhaitent disposer d’un choix. Elle rend aussi les motivations d’IBM plus difficiles à interpréter. Un acheteur doit déterminer si IBM sélectionne la technologie en fonction du flux de travail ou privilégie le partenariat bénéficiant de la dynamique commerciale la plus forte.
OpenAI fait face à un compromis similaire. L’entreprise veut que les cabinets de conseil élargissent sa distribution, mais ces cabinets peuvent aussi recommander des modèles concurrents. IBM peut placer GPT-5.6 aux côtés de Gemini, des modèles watsonx, de modèles à poids ouverts ou de systèmes spécialisés lorsqu’un client l’exige.
Le résultat n’est pas une alliance exclusive traditionnelle. Il s’agit d’un partenariat de distribution et d’implémentation au sein d’un portefeuille plus large. IBM accède à la demande pour OpenAI, et OpenAI bénéficie de la présence d’IBM auprès des entreprises. Chaque partie conserve d’autres options.
Cette structure limite l’enfermement entre les partenaires, mais elle ne protège pas automatiquement les clients. Un flux de travail peut toujours devenir dépendant du comportement d’un modèle, des outils d’un consultant ou d’une couche propriétaire d’agents et d’intégrations.
Les acheteurs en entreprise devraient donc comparer les architectures opérationnelles, et non les logos des partenariats. Ils doivent savoir si les prompts, les évaluations, les systèmes de retrieval et les règles d’approbation peuvent passer d’un modèle à l’autre. Ils devraient également demander quels composants IBM gère et lesquels restent sous le contrôle du client.
Une IA d’entreprise sécurisée exige davantage qu’un discours sur la gouvernance
La partie la plus solide du partenariat est son socle de sécurité, mais ce socle met également en lumière les questions les plus difficiles que l’accord laisse sans réponse.
IBM a rejoint le OpenAI Daybreak Cyber Partner Program le 22 juin. Ce programme donne aux fournisseurs de sécurité approuvés accès à des capacités avancées pour des travaux défensifs autorisés.
Le premier service d’IBM utilise une couche de sécurité alimentée par Consulting Advantage. Une couche de sécurité est une couche de contrôle qui limite la manière dont un système d’IA accède au code, aux outils et aux environnements clients.
IBM affirme que sa conception peut fonctionner dans l’environnement d’un client avec un accès en lecture seule aux dépôts et une exécution encadrée. L’exécution encadrée restreint les actions qu’un modèle peut effectuer, réduisant le risque qu’une analyse se transforme en modification non contrôlée du système.
Le service est destiné à analyser l’exposition des applications, à identifier les chemins d’attaque pertinents et à prendre en charge une surveillance continue à mesure que le code et les menaces évoluent. IBM a annoncé que son premier service de sécurité applicative était disponible au moment de son adhésion à Daybreak.
Cette approche répond à une préoccupation fréquente concernant les outils de sécurité basés sur l’IA. Donner à un modèle très performant un accès sans restriction au code et à l’infrastructure peut créer son propre risque. L’accès en lecture seule et l’exécution contrainte imposent des limites opérationnelles plus étroites.
IBM a également associé Daybreak à Project Lightwell, une initiative centrée sur les chaînes d’approvisionnement de logiciels open source. L’entreprise a déclaré qu’IBM et Red Hat avaient engagé 5 milliards de dollars dans le projet, qui combine une plateforme de coordination de la sécurité avec des ingénieurs chargés de corriger et de valider le code.
Le programme Daybreak plus large d’OpenAI reflète une évolution de la sécurité défensive. Les modèles deviennent meilleurs pour trouver des vulnérabilités, mais les organisations peinent encore à prioriser, corriger, tester et déployer les correctifs.
Les capacités avancées posent aussi un problème de double usage. Le même raisonnement qui aide un défenseur à valider une vulnérabilité peut aider un attaquant à l’exploiter. OpenAI limite donc certaines fonctions cyber aux organisations vérifiées et aux environnements autorisés.
GPT-5.6 renforce ce dilemme. OpenAI fait état de gains significatifs en revue de code sécurisée, correction, modélisation des menaces et tests de vulnérabilité. Ses résultats publiés incluent des scores supérieurs à ceux de GPT-5.5 dans plusieurs évaluations cyber.
Par exemple, OpenAI indique que GPT-5.6 Sol a obtenu 73,5 % sur ExploitBench, contre 47,9 % pour GPT-5.5. Il a atteint 71,2 % sur SEC-Bench Pro, contre 45,8 % pour le modèle précédent.
Il s’agit de résultats de benchmarks publiés par le fournisseur, et non d’une preuve de performances sûres dans l’environnement d’un client IBM. Un benchmark isole une tâche définie. Un flux de production introduit des inventaires incomplets, une propriété ambiguë, des dépendances changeantes et des priorités opérationnelles concurrentes.
Le partenariat entre IBM et OpenAI doit également traiter l’injection de prompt. Cette attaque manipule un système d’IA au moyen d’instructions malveillantes dissimulées dans des documents, des sites web ou du contenu récupéré. Un modèle connecté à des outils internes peut considérer ce contenu comme une commande, à moins que le système environnant ne sépare les données de l’autorité.
La gouvernance des données constitue un autre défi. Un agent utilisé dans les ressources humaines peut rencontrer des dossiers d’emploi, des informations sur les performances ou des aménagements médicaux. Un agent utilisé en finance peut accéder à des prévisions, des paiements et des historiques de transactions.
La sécurité ne peut donc pas rester un document de politique ajouté après le déploiement. Elle doit apparaître dans la conception des identités, la minimisation des données, les autorisations d’outils, la journalisation, les tests et la réponse aux incidents. Les examinateurs humains doivent disposer d’une autorité claire pour arrêter ou annuler les actions automatisées.
La couche de sécurité contrôlée d’IBM constitue un point de départ crédible. Pourtant, ce nouveau partenariat couvre bien plus que l’analyse de code. IBM n’a pas détaillé publiquement comment ces mêmes contrôles s’appliqueront à la finance, aux achats, au service client et aux ressources humaines.
L’accord ne précise pas non plus comment les clients évalueront les mises à jour de modèles. GPT-5.6 peut se comporter différemment d’une version antérieure, même lorsqu’un flux de travail conserve les mêmes instructions. Les entreprises ont besoin de tests de régression qui mesurent l’exactitude, la conformité aux politiques et les comportements dangereux avant que les changements n’atteignent la production.
Tant qu’IBM ne publiera pas d’éléments de preuve de mise en œuvre, le déploiement sécurisé restera un engagement plutôt qu’un résultat démontré. Les acheteurs doivent distinguer les fonctionnalités de sécurité qui existent aujourd’hui des futures intégrations décrites comme des objectifs du partenariat.
Le compromis central oppose la rapidité au contrôle du client
IBM peut raccourcir le chemin entre le pilote et la production, mais chaque raccourci doit préserver la capacité du client à inspecter, gouverner et remplacer le système.
Les grandes entreprises répètent souvent le même travail de préparation dans leurs projets d’IA. Les équipes mettent en place des contrôles d’accès, connectent les données, définissent des évaluations, créent des flux d’approbation et documentent les risques. Des actifs réutilisables peuvent réduire cette duplication.
Une pratique OpenAI dédiée devrait également faciliter l’identification de l’expertise. Au lieu d’assembler une équipe à partir de groupes sans lien entre eux, IBM peut affecter des consultants formés aux mêmes produits et méthodes de prestation.
Les activités commerciales conjointes peuvent simplifier les achats. Les clients peuvent s’adresser à une seule relation de prestation pour les modèles, la mise en œuvre et les services managés. Cela réduit la coordination entre plusieurs fournisseurs.
Toutefois, la rapidité d’intégration peut masquer des décisions architecturales. Un agent réutilisable peut arriver avec des hypothèses sur les formats de données, le comportement du modèle ou la surveillance. Ces hypothèses deviennent coûteuses à modifier une fois le flux de travail déployé dans plusieurs départements.
Les entreprises doivent conserver le contrôle sur quatre couches. La première concerne l’accès aux données, notamment les sources qu’un agent peut lire et les enregistrements qu’il ne doit jamais récupérer. La deuxième est l’autorité d’action, qui détermine ce que l’agent peut modifier.
La troisième couche est l’évaluation. Les clients ont besoin de leurs propres cas de test, seuils d’acceptation et historiques du comportement des modèles. Ils ne devraient pas dépendre entièrement d’un benchmark ou d’une démonstration du fournisseur.
La quatrième couche est la portabilité. Un flux de travail doit identifier quels composants appartiennent à IBM, OpenAI, un autre fournisseur ou au client. Cette cartographie détermine la difficulté d’un futur changement de modèle ou de service.
Cette exigence est importante parce qu’IBM prend ouvertement en charge plusieurs fournisseurs de modèles. Une architecture multi-modèles peut réduire la dépendance, mais uniquement si le changement est techniquement réaliste. Une liste déroulante contenant plusieurs modèles ne garantit pas un comportement équivalent.
Les changements de modèle peuvent modifier les appels d’outils, le formatage, les modes de raisonnement et le comportement de refus. Les équipes doivent tester l’ensemble du processus après un changement. Elles peuvent aussi devoir réviser les prompts, les autorisations et les critères d’évaluation.
La responsabilité humaine ne peut pas disparaître au sein d’un service managé. Si une décision d’achat assistée par l’IA est contestée, le client doit pouvoir reconstituer les données utilisées et identifier qui a approuvé le résultat. Si du code généré provoque une interruption de service, les équipes doivent disposer d’archives du changement proposé et de ses tests.
Les travailleurs du savoir font face à un risque parallèle lorsqu’ils automatisent la recherche, les synthèses et les décisions. Les systèmes utiles préservent les liens entre les résultats et les sources. Une base de connaissances interrogeable peut soutenir cette traçabilité pour les documents techniques, mais les contrôles organisationnels doivent toujours déterminer l’accès et la conservation.
Le meilleur résultat associerait une mise en œuvre plus rapide à une gouvernance client renforcée. IBM pourrait fournir des modèles éprouvés tout en laissant les politiques, les éléments de preuve et l’autorité finale sous le contrôle du client.
Le résultat plus faible consisterait à regrouper modèles et services dans une boîte noire difficile à auditer. Cela pourrait permettre de livrer rapidement un pilote impressionnant, puis créer une dépendance à long terme et des coûts de revue.
C’est pourquoi l’accord entre IBM et OpenAI doit être jugé à l’aune de son architecture et de ses preuves opérationnelles. L’ampleur du partenariat est pertinente, mais la répartition du contrôle déterminera si les déploiements restent gérables.
Trois signaux montreront si le partenariat fonctionne
La prochaine phase sera déterminée par des preuves en production, une adoption mesurable et des contrôles qui résistent au contact de flux de travail réels.
Le premier signal est un déploiement client nommé dans une opération centrale. Un cas crédible devrait identifier le flux de travail, son processus antérieur, le degré d’automatisation et le modèle de revue humaine. Il devrait rendre compte des résultats opérationnels sans s’appuyer uniquement sur des anecdotes d’employés.
La finance, les achats, le service client et les ressources humaines sont tous des domaines prometteurs. Ils comportent également des exigences juridiques, de sécurité et de qualité différentes. Les preuves issues d’un flux de travail ne peuvent pas automatiquement en valider un autre.
Un cas publié impliquant la modernisation d’applications anciennes serait particulièrement instructif. Il pourrait montrer comment Codex fonctionne avec une documentation incomplète, de nombreuses dépendances et des tests obligatoires. Il devrait également décrire comment IBM traite les changements générés qui échouent à l’évaluation.
Le deuxième signal est le niveau de préparation réel de la pratique dédiée. IBM indique prévoir de former des milliers de consultants et d’ingénieurs via le OpenAI Partner Network. Les lecteurs devraient surveiller les certifications obtenues, la couverture régionale, la spécialisation sectorielle et les équipes clients actives.
Les effectifs seuls ne régleront pas la question. La mesure pertinente est de savoir si les équipes formées peuvent amener de façon répétée des projets en production. IBM devrait à terme distinguer les personnes ayant achevé leur formation des spécialistes qui livrent des systèmes audités.
Le troisième signal est une documentation technique sur la gouvernance et la portabilité. IBM devrait expliquer comment Consulting Advantage gère la sélection des modèles, l’identité, la journalisation, les évaluations, les autorisations d’outils, les mises à jour et la réponse aux incidents dans les déploiements OpenAI.
Les clients devraient également rechercher des preuves que les flux de travail peuvent intégrer un autre modèle lorsque les exigences changent. Les relations d’IBM avec Google Cloud, Microsoft, AWS et les fournisseurs de modèles ouverts rendent cette attente raisonnable.
Ces signaux renforceraient l’affirmation centrale du partenariat. Un cas de production montrerait que l’intégration fonctionne. Des indicateurs de prestation montreraient que la nouvelle pratique est opérationnelle. Une documentation de gouvernance montrerait que l’échelle n’exige pas d’abandonner le contrôle.
Leur absence affaiblirait le récit. Si IBM ne publie que des chiffres de formation et un langage général sur la transformation, l’initiative pourrait rester principalement un canal de vente. Si les déploiements clients omettent les taux d’échec ou les coûts de revue, les acheteurs ne disposeront pas des informations nécessaires à la comparaison.
Les résultats de GPT-5.6 d’OpenAI montrent pourquoi les entreprises sont intéressées. La famille de modèles cible le travail professionnel complexe, l’ingénierie logicielle, l’utilisation d’outils, les contextes longs et la cybersécurité. Ces capacités peuvent soutenir des flux de travail précieux.
Le défi restant est organisationnel, et pas seulement technique. Les entreprises doivent relier l’intelligence à des données fiables, des autorisations limitées, des personnes responsables et des processus qui tolèrent les erreurs.
C’est la véritable opportunité derrière IBM OpenAI. IBM peut rapprocher les modèles d’OpenAI des systèmes où se déroule un travail aux conséquences importantes. Il peut également apporter l’expérience sectorielle nécessaire pour reconnaître les situations où l’automatisation doit s’arrêter.
Les acheteurs en entreprise devraient désormais demander des preuves à cette frontière. Quelles actions l’agent peut-il effectuer, qui les approuve, comment les erreurs sont-elles détectées, et le flux de travail peut-il survivre à un changement de modèle ? Le partenariat devient significatif lorsque IBM et OpenAI répondent à ces questions par des systèmes opérationnels, et non par des déclarations plus ambitieuses.


