Claude Code, Codex, Kimi Work ou architecture ouverte : comment choisir

AIDE À LA DÉCISION · CHOIX DE PLATEFORME

Placer l’outil sur le travail, pas sur la démonstration

La carte est une hypothèse de départ, pas un classement. Elle sépare la rapidité d’adoption du contrôle et de la réversibilité, et doit être vérifiée sur du travail représentatif.

01Positionnement indicatif · à vérifier avec le même dossier d’essai

Contrôle et réversibilité ↑limites fixées par l’entrepriselimites fixées par le produit

CONSTRUIRE / MAÎTRISERADOPTER / ENCADRERChatGPT Enterpriseespace de travailClaude Enterprisetravail de connaissanceClaude CodedéveloppementCodexagent de codeKimi Workagent de posteKletronorchestrationArchitecture ouvertecontrôles maîtrisésLe choix

plus lent / plus à construireRapidité d’adoption →plus rapide / plus intégré

02Adéquation par type de travail

Un gagnant unique est rarement la bonne réponse. Choisissez une architecture principale, puis dites où une seconde apporte une vraie valeur.

Type de travailEspace de travailAgent de codeAgent de posteArchitecture ouverteOrchestration

Travail de connaissance courantfortfaiblemoyenmoyenmoyen

Développement logicielmoyenfortfaiblemoyenmoyen

Fichiers et poste localmoyenfaiblefortfaiblemoyen

Produit différenciantfaiblemoyenfaiblefortfort

L’unité d’évaluation est une tâche terminée, pas une réponse du modèle.

« Quel outil d’IA devons-nous choisir ? » ressemble à une question de produit. En entreprise, c’est une décision d’architecture qui engage les données, les identités, les processus, les contrôles, les coûts et la capacité à changer de cap.

Les produits ne font pas la même chose. Claude et ChatGPT Enterprise couvrent le travail de connaissance au sens large ; Claude Code et Codex travaillent dans le code et changent la façon de développer des logiciels ; Kimi Work, édité par la société chinoise Moonshot AI, propose des agents qui travaillent sur les fichiers locaux, le navigateur et des tâches récurrentes ; Kletron, le produit d’agents développé et exploité par Numezis, orchestre plusieurs agents sur des missions métier. Les modèles à poids ouverts, enfin, permettent d’héberger soi-même. La bonne réponse dépend du travail à faire, pas du tableau des fonctionnalités.

Nous configurons et intégrons ces produits au quotidien : réglages, connexions à vos logiciels (notamment par le protocole MCP), essais, droits d’accès et contrôles en production. Connaître les produits compte, mais la décision d’architecture passe avant.

Décrire le travail avant de choisir le produit

Tracez d’abord la frontière de confiance autour du travail. Que peut lire le système ? Que peut-il retenir ? Quels outils peut-il appeler ? Que peut-il modifier ? Où une personne doit-elle confirmer ? Quelles traces doivent rester disponibles une fois le travail terminé ?

Ces questions changent tout de suite la liste des candidats. Un espace de travail d’entreprise convient à la rédaction et à l’analyse ; un agent de code a sa place dans un dépôt isolé ; un agent qui travaille sur les fichiers d’un poste se teste dans un périmètre très restreint ; une architecture ouverte se justifie pour un produit différenciant, non parce que « ouvert » serait plus sûr, mais parce que l’entreprise a besoin de maîtriser des contrôles qu’un produit en ligne n’expose pas.

Tester chaque candidat avec le même dossier d’essai

Les démonstrations commerciales montrent l’aisance ; un dossier d’essai commun montre ce qui compte pour décider. Mêmes tâches, mêmes documents, mêmes droits, même grille d’évaluation, mêmes hypothèses de coût pour chaque candidat. Incluez les cas limites : documents incomplets, consignes contradictoires, contenus en plusieurs langues, champs confidentiels, consigne piégée cachée dans un document, panne d’un outil, demande d’action irréversible.

Le dossier produit six résultats :

1. Qualité : exactitude, complétude, fidélité aux sources, effort de relecture.
2. Fiabilité : résultats reproductibles, comportement en cas de panne ou de délai.
3. Contrôles : ce que le système refuse, ce qu’il fait confirmer, ce qu’il journalise.
4. Effort d’intégration : identités, connecteurs, interfaces, environnements, charge de support.
5. Coût complet : licences ou consommation, mise en place, relecture humaine, exploitation, sortie.
6. Réversibilité : ce qui s’exporte, ce qu’il faudrait reconstruire, ce qui devient une dépendance.

Ne résumez pas le dossier en une note unique. Un candidat peut gagner sur la qualité et perdre la décision parce qu’il ne respecte pas le périmètre de données exigé.

Les données d’abord : où sont-elles traitées ?

Pour chaque candidat, vérifiez où les contenus sont traités et stockés, combien de temps ils sont conservés, s’ils peuvent servir à améliorer le service, et sur quelle base juridique un transfert hors de Suisse est possible (pays reconnu comme adéquat, certification au Swiss-US Data Privacy Framework, clauses contractuelles types). C’est un point d’attention particulier pour Kimi Work : tant que le traitement en Chine ou hors de Suisse et de l’UE n’est pas couvert par des garanties suffisantes, n’y mettez ni données de clients ni données protégées. Notre analyse nLPD, AI Act et IA générative détaille ces règles.

Quatre architectures types

L’espace de travail géré (ChatGPT Enterprise, Claude Enterprise, Copilot). Le bon choix par défaut pour un usage large en interne : identités, administration et accès aux modèles au même endroit. En contrepartie, vous acceptez les limites du produit et devez vérifier comment sont gérés les données, les connecteurs, la conservation et les changements de modèle.

L’interface de programmation gérée (API d’un fournisseur de modèles). Le bon choix pour une application différenciante ou un processus contrôlé : vous maîtrisez l’expérience, l’orchestration, la recherche documentaire et les règles. En contrepartie, la réalisation et l’exploitation sont à votre charge : une API n’est pas un service complet.

L’agent de code ou de poste de travail (Claude Code, Codex, Kimi Work). Le bon choix quand le travail vit dans des fichiers, un dépôt de code, un terminal ou un navigateur. En contrepartie, la surface d’action est plus large : isolation, droits locaux, secrets, sessions de navigateur et relecture humaine deviennent votre responsabilité.

L’architecture ouverte ou hébergée chez vous. Le bon choix quand le contrôle, le lieu d’hébergement, la structure de coûts ou la différenciation justifient de tout maîtriser. En contrepartie, il ne s’agit pas seulement de serveurs : essais des modèles, mises à jour, capacité, sécurité, réponse aux incidents et support sont à vous.

Une combinaison est souvent rationnelle, à condition que les frontières soient écrites : l’espace de travail pour l’usage courant à faible risque, l’agent de code pour le développement, une interface de programmation pour un processus tourné vers les clients, un modèle ouvert seulement là où le contrôle l’exige. Un empilement d’outils sans frontières crée des identités en double, des règles de données incohérentes et aucun responsable.

Comparer le coût par dossier traité

La question n’est presque jamais « prix par utilisateur contre prix par requête ». Comparez le coût complet par dossier traité avec succès : plateforme, consommation, intégration, préparation des données, essais, relecture humaine, exploitation, changements et sortie. Puis comparez-le au coût actuel, travail refait et délais compris. Un outil bon marché par requête coûte cher par dossier si les utilisateurs doivent corriger la plupart des résultats.

Faites trois scénarios : pilote, volume attendu, et scénario difficile (plus de volume, documents plus longs, taux de réussite plus bas, changement de modèle, relecture renforcée). Le but n’est pas un chiffre précis, mais de repérer l’hypothèse qui renverserait la décision.

Écrire la décision et la porte de sortie

Une bonne fiche de décision décrit le contexte, les options, les résultats du dossier d’essai, le choix retenu, les risques acceptés et les conditions de réexamen. Elle décrit aussi la sortie en cinq lignes : format d’export des données, liste des intégrations, possibilité de réutiliser les essais, dépendances des utilisateurs et formations, délai estimé pour un remplacement crédible. On la revoit quand le contrat, le prix, le comportement du modèle ou l’importance du processus changent.

La bonne réponse n’est pas « nous sommes neutres vis-à-vis des fournisseurs ». C’est « nous savons pourquoi cette architecture gagne pour ce travail, ce que nous acceptons, et quelles options nous avons gardées ».

Comment nous pouvons aider

Le choix et la configuration d’un espace de travail pour vos équipes relèvent de l’Accompagnement IA. Le dossier d’essai, l’intégration à vos logiciels, les agents et les architectures sur mesure relèvent de l’offre Engineering IA : cadrage de une à trois semaines, puis devis ferme, ou abonnement si plusieurs chantiers s’enchaînent. Pour une PME qui hésite entre ChatGPT, Claude, Gemini et Copilot, l’analyse lequel choisir pour une PME est plus directe.