DECISION TOOLKIT · SÉLECTION DE PLATEFORME
Positionner l’outil sur le travail, pas sur la démo
La carte est une hypothèse de départ, pas un benchmark. Elle sépare la vitesse d’accès à la valeur du contrôle et de la réversibilité, puis oblige à valider la position sur du travail représentatif.
Un gagnant unique est généralement la mauvaise sortie. Sélectionner un pattern principal, puis définir où un second crée une valeur matérielle.
L’unité d’évaluation est un workflow terminé, pas une réponse du modèle.
« Quel outil IA devons-nous choisir ? » ressemble à une question produit. Dans l’entreprise, c’est une décision d’architecture portant sur données, identités, workflows, contrôles, économie et capacité à changer de direction.
Claude et ChatGPT Enterprise couvrent largement le travail de connaissance ; Claude Code et Codex transforment le software delivery ; Kimi Work apporte des workflows agentiques aux fichiers locaux, navigateurs et tâches récurrentes. Kletron — le produit agent et multi-agent développé par Numezis et déjà utilisé par des PME — ajoute une couche d’orchestration complète pour les missions business complexes. Les architectures open weight créent encore d’autres options de contrôle et d’intégration. Ces systèmes ne sont pas interchangeables, et une simple comparaison de fonctionnalités reste insuffisante : la réponse dépend du workflow que l’organisation cherche à opérer.
Numezis travaille concrètement avec ces produits sur la configuration, les workflows de code, les tools et intégrations MCP, l’évaluation, le design des permissions et les contrôles de production. La maîtrise produit compte, mais elle doit rester subordonnée à la décision d’architecture.
Définir le travail avant le produit
Spécifiez workflow, utilisateurs, systèmes touchés, catégories de données, actions permises et résultat attendu. Distinguez productivité individuelle, travail collaboratif, software engineering, applications clients et actions autonomes. Chaque cas crée une frontière de confiance différente.
Ne demandez pas quel modèle est « le meilleur » dans l’absolu. Constituez un set d’évaluation représentatif du travail réel et fixez des seuils de qualité, latence, fiabilité et coût.
Évaluer six dimensions
1. Frontières des données
Cartographiez entrées, contexte, sorties, télémétrie et contenu retenu. Déterminez où chacun circule, combien de temps il reste et s’il peut servir à améliorer le service. Les frontières contractuelles et techniques doivent coïncider.
2. Intégration
Un assistant isolé crée parfois une productivité locale mais peu de levier opératoire. Évaluez identité, permissions, API, connectivité MCP, retrieval, événements et capacité à intégrer les contrôles aux workflows existants.
3. Sécurité et gouvernance
Considérez administration, contrôle d’accès, preuves d’audit, data loss prevention, permissions des tools, dépendances, réponse à incident et gestion des changements de modèle. Pour les agents, chaque outil connecté étend la surface d’attaque et de défaillance.
4. Performance
Mesurez sur la tâche réelle. Un produit peut exceller en rédaction et être moins fort pour le code, le long contexte, l’extraction structurée ou l’usage de tools. La qualité évolue ; les évaluations doivent être répétables.
5. Économie complète
La licence n’est qu’une composante. Incluez inférence, intégration, préparation des données, évaluations, support, change management et validation humaine. Comparez le coût par résultat réussi du workflow, pas seulement le coût par token.
6. Réversibilité
Identifiez ce qui devient propriétaire : prompts, agents, intégrations, données d’évaluation, habitudes utilisateurs et index de connaissances. Standards et abstraction aident, mais l’abstraction inutile coûte aussi. Préservez la flexibilité là où l’option future a une valeur matérielle.
Adapter le déploiement au risque
Le SaaS peut offrir l’adoption la plus rapide et l’expérience la mieux intégrée. Les API cloud donnent plus de contrôle produit. Les modèles locaux ou self-hosted modifient les frontières data et opérationnelles, mais transfèrent plus de responsabilités à l’entreprise. Une architecture hybride est souvent rationnelle lorsque les workflows ont des exigences différentes.
| Pattern | Bon contexte | Compromis principal |
|---|---|---|
| SaaS entreprise | adoption large du travail de connaissance | frontière produit et dépendance fournisseur |
| API de modèle managée | applications différenciantes | ownership engineering et opérations |
| Self-hosted/open weight | besoins précis de contrôle ou économie | responsabilité du cycle complet |
| Hybride | workflows et niveaux de risque variés | complexité d’architecture et gouvernance |
Documenter la décision et la sortie
Un bon architecture decision record décrit contexte, options, preuves, pattern retenu, risques acceptés et conditions de réexamen. Il expose aussi la sortie : comment données, intégrations et évaluations pourraient migrer si le produit, les conditions ou la performance changent.
Le but n’est pas une neutralité permanente. L’entreprise doit faire un choix actuel fort sans en faire accidentellement un choix irréversible.