Cohere North 2 : ce qu’une plateforme d’agents d’entreprise change — et ce qu’il faut vérifier

La nouvelle en bref : des agents que l’entreprise peut réutiliser et encadrer

Le 5 octobre 2026, Cohere a présenté North 2, une nouvelle version de sa plateforme d’agents pour organisations. Dans son annonce, l’entreprise met l’accent sur trois choses : composer des agents et des automatisations réutilisables, les relier à des outils métier, puis donner aux administrateurs davantage de visibilité sur l’usage et les règles d’autonomie.

La nouveauté intéresse surtout les organisations qui veulent tester des assistants capables de suivre un processus plutôt que de simplement répondre à une question. Par exemple, un agent pourrait retrouver une procédure interne, préparer un résumé et proposer une mise à jour de ticket. Mais l’agent ne devrait pas automatiquement publier cette mise à jour ou envoyer un message : cette séparation entre préparer et agir est le point à concevoir, pas un détail de configuration.

North 2 est une annonce de fournisseur. Les capacités décrites ci-dessous sont celles que Cohere déclare proposer ; elles ne constituent pas une évaluation indépendante de leur fiabilité, de leur sécurité ou de leur intérêt économique pour une entreprise française.

À retenir : North 2 vise la création et la gouvernance d’agents d’entreprise. Avant de choisir, demandez une démonstration sur un cas limité, les conditions de traitement des données, les prix et la disponibilité contractuelle qui s’appliquent à votre organisation.

Ce que Cohere annonce exactement

Cohere décrit North 2 comme un « agent harness » : un environnement permettant de créer et d’organiser des agents construits autour de tâches, d’outils et d’automatisations. L’entreprise indique que la plateforme est model-agnostic, c’est-à-dire conçue pour orchestrer différents modèles plutôt que d’en imposer un seul dans tous les usages. Cela ne garantit pas que chaque modèle soit disponible dans chaque déploiement ou aux mêmes conditions.

L’annonce parle de bibliothèques partagées d’agents, de compétences et de mémoire, ainsi que de contrôles d’administration. Cohere affirme que North Admin peut fournir une visibilité par utilisateur sur l’usage, les dépenses en tokens, les quotas et les limites. Les politiques d’autonomie, garde-fous et journaux d’audit font également partie des contrôles annoncés.

Pour les connexions, l’article de Cohere cite Slack, SharePoint, OneDrive, Microsoft Outlook et Exchange, Jira, Linear, Notion et GitHub. Des connecteurs à des données financières apparaissent dans la liste des développements prévus : ne les traitez pas comme disponibles avant confirmation écrite et test dans l’environnement qui vous concerne.

Cohere présente plusieurs possibilités de déploiement, dont le cloud, l’environnement sur site et l’air-gapped (isolé d’Internet). La documentation du Model Vault décrit par ailleurs une configuration où l’application North est dans le VPC du client tandis que l’inférence passe par le service géré de Cohere. Cette documentation est une architecture précise de Model Vault ; elle ne prouve pas que tous les comptes North 2, contrats ou connecteurs partagent le même chemin de données.

Ce que l’annonce ne permet pas encore de conclure

La page publique ne donne pas de grille tarifaire, de coût par utilisateur, de coût de mise en place, de minimum contractuel ni de prix des modèles ou intégrations. Le bouton de contact commercial indique qu’une discussion avec Cohere est proposée ; il ne permet pas de déduire un prix ni une offre particulière.

Les pages examinées ne confirment pas non plus une disponibilité générale en France, la région de traitement d’un compte européen, les options contractuelles de protection des données ou le niveau de service. Une page qui mentionne un déploiement sur site ou isolé n’est pas à elle seule une garantie que ces options sont incluses dans votre contrat, compatibles avec chaque connecteur ou exploitables par votre équipe.

Enfin, une fonction de journalisation ou un réglage d’autonomie n’assure pas que l’agent comprendra correctement une procédure, respectera toujours son périmètre ou résistera à des instructions malveillantes présentes dans un document. Il faut tester les comportements réels, y compris les erreurs et les tentatives de détournement, dans un espace sans données ni actions critiques.

Ne confondez pas « fonction annoncée », « option documentée », « disponible dans votre contrat » et « validée en production ». Ce sont quatre vérifications distinctes.

À qui cela peut servir — et à qui probablement pas

L’offre semble d’abord viser les équipes informatiques, sécurité, données et métiers des organisations qui gèrent déjà des identités, des accès et des processus internes. Une entreprise avec plusieurs outils connectés peut étudier si une couche commune d’agents évite de multiplier les prototypes isolés. Les secteurs réglementés peuvent y voir une piste à examiner, mais l’existence de journaux ou de déploiements isolés ne constitue pas une validation réglementaire.

Pour une petite entreprise, un indépendant ou un particulier, une plateforme d’entreprise peut être disproportionnée si le besoin se résume à résumer des courriels ou rédiger des brouillons. Le temps d’intégration, la gestion des accès, le contrat, les tests, la formation et le suivi peuvent coûter davantage que le gain procuré par l’automatisation. Comme aucun prix public n’est annoncé, il faut obtenir une proposition et la comparer au coût d’un processus simple avec un assistant déjà autorisé.

Un bon premier filtre est concret : avez-vous un processus répétitif, stable, mesurable, avec une personne responsable et des données dont l’usage est autorisé ? Si la réponse est non, commencez par clarifier le processus plutôt que par déployer un agent.

1. Pertinent à étudier : une équipe possède déjà les outils, les responsabilités et une tâche répétitive à faible risque.
2. À différer : le processus change souvent, les exceptions sont nombreuses ou personne n’est responsable du résultat.
3. Probablement excessif : usage individuel occasionnel sans besoin d’intégration ni de contrôle centralisé.
4. À exclure pour un premier essai : décisions de recrutement, paiement, santé, droit, accès privilégié ou communication irréversible.

Les permissions sont le vrai sujet de sécurité

Un agent relié à une boîte mail, un dépôt de code ou un espace documentaire hérite d’une partie de l’autorité de ces outils. Si on lui donne un droit d’écriture trop large, une erreur de compréhension peut devenir une action réelle. OWASP recommande pour les agents d’appliquer le moindre privilège, de limiter les outils et les permissions à la tâche, d’exiger une approbation humaine pour les opérations à impact élevé, et de journaliser les actions. Ce sont des principes généraux de sécurité, pas une affirmation sur les paramètres par défaut de North 2.

La première version d’un agent devrait recevoir uniquement les accès dont elle a besoin, idéalement dans un environnement de test ou avec des données fictives. Pour un agent de tri de demandes, un droit de lecture sur une boîte dédiée et la capacité de préparer un brouillon peuvent suffire. L’envoi, la suppression, le partage externe ou la modification des dossiers restent manuels tant que les tests ne démontrent pas une maîtrise fiable des cas limites.

Les documents eux-mêmes peuvent contenir des instructions trompeuses — par exemple demander à l’agent de divulguer un dossier ou d’ignorer ses règles. Un agent ne doit pas traiter le texte d’un document comme une autorisation supplémentaire. Les droits doivent être contrôlés par le système connecté, pas négociés à partir de ce que le modèle lit.

1. Créer une identité technique distincte par agent ou cas d’usage, sans réutiliser un compte administrateur.
2. Accorder le minimum : un espace ou dossier précis, une portée limitée, une durée d’accès définie.
3. Démarrer en lecture seule ; si nécessaire, permettre la préparation de brouillons plutôt que leur envoi.
4. Mettre une validation humaine avant toute écriture, publication, suppression, paiement ou partage externe.
5. Journaliser qui a lancé quoi, quelle source a été utilisée, quelle action a été proposée et qui l’a approuvée.

Une méthode d’évaluation en quatre étapes

Avant toute démonstration, écrivez le résultat attendu et les cas où l’agent doit s’arrêter. Un objectif comme « gérer les demandes clients » est trop large. « Résumer les demandes reçues dans une boîte de test, extraire les informations présentes et signaler les champs manquants sans répondre au client » est vérifiable.

Préparez ensuite un jeu d’essai avec des exemples normaux, incomplets, contradictoires et malveillants. Les données doivent être fictives ou anonymisées tant que la sécurité et les conditions de traitement ne sont pas établies. Notez les erreurs de faits, les informations inventées, les actions proposées et le temps de correction nécessaire.

Enfin, fixez un budget et des bornes d’exécution. Les agents peuvent répéter des appels, solliciter plusieurs outils ou rester bloqués sur une tâche. Prévoyez un nombre maximum de tentatives, une limite d’usage, un délai d’arrêt, une alerte en cas d’échec et un moyen de désactiver les accès.

1. Définir une seule tâche, son responsable, les sources autorisées et les actions interdites.
2. Évaluer au moins vingt cas, dont des entrées incomplètes, ambiguës et des instructions hostiles.
3. Mesurer exactitude, omissions, faux positifs, temps humain de contrôle, latence et coût total observé.
4. Faire relire les journaux par la sécurité et le métier, puis décider de corriger, poursuivre ou arrêter.
5. Répéter les tests après toute modification du modèle, des outils, des instructions ou des permissions.

Cas pratique fictif : préparer une réponse sans l’envoyer

Imaginons une équipe support de huit personnes qui reçoit des demandes de suivi dans un outil de tickets. Son problème n’est pas de répondre automatiquement, mais de réduire le temps consacré à trouver la procédure applicable. Ce scénario est fictif : il illustre une méthode, pas un client de Cohere ni un résultat mesuré.

L’équipe peut tester un agent qui lit uniquement une base de procédures de test et trois tickets synthétiques. Il prépare un résumé, indique les passages de procédure utilisés, puis propose un brouillon sans le publier. Une personne compare chaque élément à la source, corrige les erreurs et note si l’agent a reconnu les informations manquantes.

Si ce test est satisfaisant, l’étape suivante n’est pas nécessairement l’envoi automatique. L’équipe peut d’abord élargir à un groupe interne, garder la validation obligatoire et suivre le taux de corrections. Elle n’examine une action d’écriture limitée que si les autorisations, le budget, la protection des données et le mécanisme d’arrêt ont été validés séparément.

1. Données : procédures publiques ou fictives et tickets synthétiques.
2. Accès : lecture seule, espace de test, identité dédiée.
3. Sortie : résumé, sources internes, questions manquantes et brouillon non envoyé.
4. Contrôle : agent humain responsable vérifie chaque fait et chaque citation.
5. Critère d’arrêt : toute action non demandée, source inventée ou fuite de données met fin à l’essai.

Checklist avant de connecter un outil réel

L’annonce de North 2 peut être un point de départ pour une évaluation, mais pas le substitut à une revue d’achat et de sécurité. Avant une preuve de concept avec des données ou outils réels, demandez les éléments que la communication publique ne tranche pas : prix complet, disponibilité dans votre pays, lieux de traitement, sous-traitants, rétention, suppression, modalités contractuelles, support, disponibilité des connecteurs et procédure de sortie.

Demandez aussi une démonstration de l’administration des identités, des permissions par agent, des journaux d’audit, des plafonds d’usage, de l’arrêt d’urgence et des validations humaines. Faites vérifier les réponses par les responsables compétents de votre organisation. Un paramètre visible dans une interface n’est pas une garantie contractuelle ; une promesse contractuelle ne remplace pas un test technique.

1. Périmètre : une tâche et un responsable identifiés ; pas de décision sensible déléguée.
2. Données : classification, minimisation, lieu de traitement, rétention et suppression confirmés.
3. Accès : moindre privilège, identité dédiée, permissions révocables et connecteurs précisément listés.
4. Actions : lecture seule au départ, brouillons séparés des envois, validation humaine et limites d’autonomie.
5. Résilience : jeu de tests, journalisation, limite de coût, arrêt d’urgence et procédure manuelle de repli.
6. Contrat : prix total, régions, niveaux de service, support, responsabilités et conditions de réversibilité examinés.
7. Décision : comparer le bénéfice net mesuré à une méthode plus simple déjà autorisée.

Notre analyse : une annonce à évaluer, pas une raison d’automatiser davantage

North 2 met en avant une évolution importante du marché : les entreprises ne cherchent plus seulement un modèle qui écrit bien, mais une couche capable d’orchestrer des outils, de mutualiser des agents et de rendre leur usage plus visible. Cette orientation peut faciliter les essais si elle réduit la fragmentation entre prototypes et contrôles d’administration.

Mais une plateforme d’agents concentre aussi les risques : une erreur peut être propagée par un connecteur, une permission excessive élargit les dégâts possibles, et un coût d’usage difficile à prévoir complique l’exploitation. Les contrôles annoncés sont intéressants précisément parce qu’ils devront être vérifiés, testés et inclus dans une gouvernance claire.

Pour une organisation française ou européenne, la bonne prochaine action est modeste : décrire un processus non sensible, demander une démonstration encadrée et obtenir les réponses écrites sur prix, traitement, région et contrat. Si aucun gain mesurable ne justifie l’intégration, ne pas déployer est une décision raisonnable.

La valeur d’un agent ne se mesure pas au nombre d’actions qu’on lui confie, mais au travail utile qu’il accomplit dans un périmètre compréhensible et réversible.

Pour aller plus loin dans Cresora IA

Pour comparer les outils sans vous laisser guider uniquement par les annonces des éditeurs, consultez notre [guide de choix des modèles IA](/guides/choisir-modele-ia-chatgpt-claude-gemini-mistral-deepseek-qwen). Pour une autre lecture des agents reliés à un service métier, notre [analyse sur les agents IA du checkout Shopify](/guides/shopify-checkout-agents-ia-acheteur-securite-limites) examine les permissions, le contrôle humain et les limites dans un contexte différent.

Ces articles ne remplacent pas une analyse de sécurité, une revue de contrat ou un avis juridique. Ils peuvent aider à préparer les questions à poser et à séparer les capacités annoncées des choix de déploiement.