IA en entreprise : Cognizant mise sur OpenAI
Cognizant mobilise 25 000 salariés autour d’OpenAI après Gemini. Analyse des usages visés, des conditions de déploiement et des risques pour les entreprises.
IA en entreprise : Cognizant mise sur OpenAI
Cognizant et OpenAI : le pari du déploiement à grande échelle
L'intelligence artificielle générative est désormais à portée de presque toutes les grandes entreprises. Mais entre un abonnement à un modèle et un outil réellement utilisé dans les opérations, il y a une marche assez évidente : connecter les systèmes, revoir les processus, former les équipes et clarifier qui valide les résultats. C'est précisément cet écart - entre l'accès à la technologie et la capacité à la faire fonctionner - que Cognizant veut mettre en avant.
Le groupe de services informatiques annonce la création d'une équipe de plus de 25 000 personnes pour déployer ChatGPT et Codex chez ses clients. Les premiers chantiers concernent le développement logiciel, la modernisation des systèmes centraux et des agents d'IA pour la vente et le service client. L'annonce arrive seulement onze jours après la mobilisation de 18 000 collaborateurs autour de Gemini, le modèle de Google.
Ces chiffres impressionnent, mais ils ne disent pas, à eux seuls, combien de projets seront réellement lancés ni quels gains seront obtenus. Pour juger la portée de la stratégie, il faut regarder les cas d'usage retenus, les éléments de preuve avancés par Cognizant et, surtout, les conditions concrètes d'un déploiement responsable, dans un contexte européen.
Pourquoi Cognizant mobilise 25 000 personnes autour d OpenAI
Le problème se situe souvent après le choix du modèle
La thèse de Cognizant est assez simple : le plus dur n'est pas toujours d'obtenir un accès à un modèle d'IA, mais de trouver les personnes capables de l'intégrer dans les systèmes et dans les pratiques d'une entreprise. Une équipe peut tester un assistant conversationnel en quelques jours ; elle ne peut pas, pour autant, le faire tourner à grande échelle dans un environnement rempli d'applications anciennes, de données dispersées et de règles métier complexes.
L'intégration demande plusieurs compétences qui ne se trouvent pas naturellement dans une seule équipe : ingénierie logicielle, sécurité, architecture des données, connaissance du métier, conduite du changement et suivi des performances. Les modèles ne suppriment pas ce travail. Ils ajoutent une couche de plus, qu'il faut raccorder au reste - puis surveiller dans la durée.
Cognizant affirme avoir formé plus de 21 000 collaborateurs, qui auraient obtenu au total plus de 40 000 badges de formation OpenAI. L'effort de montée en compétences est réel, mais il ne prouve pas que 25 000 personnes travaillent à plein temps sur des projets OpenAI. L'annonce vise surtout la capacité que l'entreprise dit pouvoir mobiliser pour ses clients, pas une photographie détaillée des équipes, des missions ou des résultats commerciaux.
Une offre de déploiement, pas seulement une offre de modèles
Ce mouvement s'inscrit aussi dans une dynamique plus large du marché. Les fournisseurs de modèles veulent accompagner leurs clients jusqu'à la mise en production. De leur côté, les sociétés de conseil et de services informatiques cherchent à se placer comme l'interface entre « les capacités » et les changements concrets dans les opérations. D'après les informations communiquées, OpenAI aurait aussi renforcé son activité de déploiement et recruté Cognizant et CGI pour introduire Codex dans les grandes entreprises.
Au final, la valeur ne dépend pas uniquement de la performance d'un modèle. Elle repose aussi sur la capacité à définir un périmètre utile, à intégrer les outils dans l'existant et à mettre en place des contrôles. Pour une direction informatique, choisir un prestataire peut accélérer l'accès aux compétences. Mais il y a aussi une question de dépendance : connecteurs, méthodes et habitudes de travail peuvent finir par s'aligner sur un fournisseur ou un écosystème.
Quels cas d usage sont prioritaires
Développer des logiciels avec Codex
Le premier axe annoncé concerne l'ingénierie logicielle. Des outils comme Codex peuvent aider sur la rédaction ou la transformation de code, l'analyse de bases existantes et certaines tâches répétitives. Dans une équipe qui maintient plusieurs applications, le bénéfice attendu n'est pas seulement « gagner du temps pour écrire ». Il peut aussi s'agir de réduire le temps passé à comprendre un système, à produire des tests ou à traiter des demandes de modification.
La productivité, cependant, dépend beaucoup du contexte. Dans un dépôt bien documenté, avec des tests fiables et des règles de revue claires, l'assistance peut accélérer le travail. Dans un système mal documenté, elle peut produire du code plausible mais faux, ou multiplier des changements difficiles à vérifier. Les entreprises doivent donc mesurer le temps total entre la demande et une livraison validée, pas uniquement le volume généré.
Moderniser les systèmes centraux
Cognizant évoque aussi la migration d'anciens systèmes centraux, notamment des mainframes, vers le cloud. Ce type de projet coûte cher et comporte des risques : les applications concernées portent souvent des processus essentiels (paiements, contrats, stocks, gestion des clients). L'IA peut contribuer à analyser du code, documenter des dépendances ou préparer des transformations, mais elle n'efface pas les contraintes d'architecture, ni la nécessité de tester ce qui sort du pipeline.
Une migration réussie suppose de choisir un périmètre, de comprendre les dépendances et de définir une stratégie de retour arrière. Automatiser une partie de l'analyse peut faire gagner du temps. Automatiser sans contrôle une transformation critique peut, au contraire, rendre les incidents plus difficiles à diagnostiquer. En pratique, l'indicateur le plus utile n'est pas la quantité de code convertie, mais la baisse du risque et du coût sur une étape précise du programme.
Agents pour la vente et le service client
Le troisième axe porte sur des agents d'IA dans la vente et le service client. Ils peuvent aider un conseiller à retrouver une information, préparer une réponse ou résumer un échange. Dès qu'un agent agit avec des outils métier, la question devient concrète : quelles actions peut-il exécuter seul, et lesquelles doivent rester validées par un salarié ?
Dans ces cas d'usage, la qualité ne se limite pas à la fluidité d'une conversation. Il faut suivre la justesse des réponses, le taux de résolution, les transferts vers un humain, les erreurs et l'expérience des clients. Pour une entreprise française ou européenne, il faut aussi regarder les données utilisées : accès, conservation, et façon dont les utilisateurs sont informés. La délimitation des permissions est autant une décision « produit » qu'une décision technique.
Comment mesurer la valeur au delà des démonstrations
Cognizant cite un exemple d'assistant d'IA conçu pour un groupe pharmaceutique mondial. L'outil aurait traité plus de cinq millions de conversations et réduit de 60 % le temps nécessaire à la création de contenus. C'est un signal intéressant : on est ici sur un volume opérationnel réel, pas uniquement sur une démo interne.
Mais ces chiffres ne suffisent pas à estimer l'impact économique. Les informations publiques ne précisent ni la période mesurée, ni la nature exacte des conversations, ni le niveau de validation humaine, ni le coût complet du dispositif. La baisse du temps de création ne dit pas, à elle seule, si le contenu final est meilleur, s'il faut moins de corrections, ou si les équipes ont été redéployées vers des tâches à plus forte valeur.
Établir une mesure avant le lancement
Avant un pilote, une équipe devrait poser une situation de référence. Pour un outil de service client, cela peut inclure le temps moyen de traitement, le taux de résolution au premier contact, les escalades et la satisfaction. Pour l'assistance au développement, il faut regarder le délai de livraison, les défauts après mise en production et le temps de revue. Sans base de comparaison, une « amélioration » peut simplement refléter un changement de périmètre ou une période atypique.
Une mesure exploitable sépare au moins trois niveaux :
- L'activité : volume de demandes, conversations ou suggestions traitées.
- La qualité : taux d'erreur, corrections nécessaires, conformité et satisfaction.
- L'impact opérationnel : coût par tâche, délai de traitement et capacité effectivement libérée.
L'usage en volume aide à comprendre l'adoption, mais ne suffit pas comme preuve de valeur. Un assistant utilisé par des milliers de personnes peut produire peu de gains si le travail doit être revérifié à chaque fois. À l'inverse, un outil plus ciblé peut afficher un résultat mesurable sur une étape coûteuse.
Organiser un passage à l'échelle avec des garde-fous
Un projet devrait démarrer avec un processus clairement identifié, un responsable côté métier et des critères de réussite définis avant le déploiement. Ensuite, il faut décider quelles données l'outil peut consulter, quelles actions il peut déclencher et quand une validation humaine est obligatoire. Ces règles doivent être testées avec des cas « normaux », mais aussi avec des exceptions, des données incomplètes et des demandes ambiguës.
Pour les entreprises européennes, il faut intégrer les obligations liées à la protection des données, à la sécurité et à la gouvernance de l'IA. Le RGPD impose de traiter les données personnelles selon un cadre défini ; ce n'est pas un simple « choix d'un fournisseur réputé ». L'AI Act européen ajoute aussi des exigences selon la nature et le niveau de risque des usages. Juristes, sécurité, métiers et informatique doivent donc être impliqués dès la conception, pas seulement au moment de « valider à la fin ».
La règle pragmatique est simple : passer à l'échelle ce qui a démontré sa valeur, avec des contrôles adaptés. Si les résultats sont difficiles à attribuer, si les erreurs restent coûteuses ou si personne n'est clairement responsable du processus, le projet n'est pas prêt pour une généralisation.
Que révèle le choix simultané d OpenAI et de Gemini
Onze jours avant l'annonce liée à OpenAI, Cognizant avait déclaré mobiliser 18 000 collaborateurs autour de Gemini, l'offre d'IA de Google. Cette proximité suggère que l'entreprise ne construit pas toute sa stratégie autour d'un seul fournisseur. Pour un prestataire qui travaille avec de grands groupes aux environnements variés, l'approche peut être commerciale - mais elle est aussi opérationnelle : les clients n'ont ni les mêmes systèmes, ni les mêmes contraintes d'achat.
Avoir plusieurs modèles peut réduire le risque de dépendance et permettre de choisir l'outil en fonction du cas d'usage. Mais ça ne rend pas automatiquement une organisation « indépendante ». Les données, les flux de travail, les compétences et les intégrations peuvent rester fortement liés à chaque plateforme. Et faire coexister plusieurs solutions a un coût : formation, gouvernance, évaluation des performances, gestion des accès et support.
La stratégie multi-fournisseur a un coût
Adopter plusieurs modèles oblige à clarifier ce qui justifie réellement leur coexistence. Un modèle peut être retenu parce qu'il s'intègre déjà à certains outils. Un autre peut être choisi pour un usage spécifique ou des exigences particulières. Sans critères communs, les équipes risquent de décider selon leurs préférences, de dupliquer des solutions et de compliquer le contrôle des données.
Un cadre de décision utile compare les options sur des critères vérifiables : qualité sur des tâches réelles, coût complet, sécurité, latence, intégration, conditions contractuelles et capacité à changer de fournisseur. Le coût complet inclut les licences, l'infrastructure, l'accompagnement, le contrôle humain et la maintenance. Un modèle moins cher à l'usage peut coûter plus cher si son intégration implique une refonte importante.
Ce que les entreprises clientes devraient demander
L'annonce de Cognizant met l'accent sur la capacité de déploiement. Mais les organisations clientes devraient vérifier ce qui est réellement inclus dans chaque mission. Elles peuvent demander qui porte la responsabilité des résultats, comment les données sont traitées, quels indicateurs seront suivis et à quel moment une équipe humaine reprend la main. Il faut aussi clarifier la propriété des livrables et la possibilité d'ajuster l'architecture.
Avant de confier un processus à un agent, un décideur peut utiliser cette grille rapide :
- Le problème est-il suffisamment coûteux ou fréquent pour justifier l'automatisation ?
- Existe-t-il une mesure de référence et un indicateur de qualité, pas seulement d'activité ?
- Les accès et les actions de l'outil sont-ils limités au nécessaire ?
- Un responsable peut-il suspendre ou corriger le système en cas d'erreur ?
- Le dispositif restera-t-il exploitable si le fournisseur ou le modèle change ?
Le volume de personnes mobilisées indique une capacité et une volonté d'aller vite. La preuve la plus importante sera ailleurs : dans la capacité à transformer ces ressources en résultats reproductibles, sans transférer les coûts vers la supervision, la sécurité ou la maintenance.
Conclusion
La décision de Cognizant montre un déplacement du marché : la bataille ne porte plus seulement sur l'accès aux modèles, mais sur les compétences nécessaires pour les intégrer dans des opérations réelles. Le développement logiciel, la modernisation des systèmes et le service client sont des terrains plausibles - à condition de mesurer le résultat au-delà du simple volume d'usage.
Pour les entreprises, le bon réflexe n'est ni de suivre l'annonce à l'aveugle, ni de rejeter l'IA par principe. Il s'agit de choisir un processus précis, de définir une référence, d'encadrer les données et les actions, puis de vérifier si le gain tient après les coûts de contrôle et de maintenance. C'est à cette échelle que les promesses deviennent de vraies décisions d'investissement.