Une plateforme d’agents avec davantage de contrôle, selon Cohere
Cohere présente North 2 comme une mise à jour de sa plateforme d’intelligence artificielle destinée aux entreprises. L’offre réunit des agents, des flux de travail et des contrôles de sécurité et de coûts au sein d’un même environnement. Plutôt que de simplement répondre à une question, un agent peut s’inscrire dans une suite de tâches nécessitant de coordonner des actions et des outils. C’est le changement d’approche proposé par l’entreprise : rapprocher les agents de processus de travail continus et donner aux organisations davantage de moyens pour les encadrer.
Il est essentiel de distinguer l’orientation du produit des capacités effectivement vérifiées. Décrire une plateforme comme un centre de contrôle ne permet pas, à lui seul, de savoir quels droits peuvent être configurés, comment les plafonds de dépenses sont appliqués ni quelles actions sont consignées. Les informations disponibles confirment que Cohere annonce des contrôles des coûts et de la sécurité, ainsi qu’une plateforme d’agents. Elles ne fournissent pas d’évaluation indépendante permettant d’affirmer que ces contrôles sont efficaces dans tous les contextes d’entreprise.
Il faut également différencier l’annonce d’une fonctionnalité de sa disponibilité et de son périmètre. Les éléments consultés ne permettent pas d’établir quelles fonctions sont accessibles à l’ensemble des clients, si certaines capacités dépendent d’une configuration particulière ni quelles conditions techniques ou commerciales s’appliquent. North 2 doit donc être considéré ici comme un produit annoncé avec certaines fonctions, et non comme une solution dont l’efficacité opérationnelle aurait déjà été démontrée.
Les flux en plusieurs étapes : une utilité potentielle, encore à évaluer
La présentation de North 2 inclut la gestion de flux en plusieurs étapes par des agents. En pratique, un tel flux pourrait enchaîner des tâches comme recueillir des informations provenant d’une source autorisée, les résumer et préparer un résultat à faire vérifier. Il s’agit d’un exemple d’usage possible, et non d’une démonstration que le produit exécute chaque étape de manière fiable ou qu’il peut mener des actions à bien sans supervision. La qualité du résultat dépendrait notamment de la conception du flux, des outils connectés et des autorisations accordées.
Pour évaluer le comportement réel, il faut observer le processus dans son ensemble, et pas seulement la réponse finale. Un test utile consignerait les étapes exécutées, les informations consultées par l’agent, les actions qu’il a tenté d’effectuer et le moment où il a demandé une intervention humaine. Il vérifierait aussi sa réaction face à des données incomplètes, des instructions contradictoires ou un outil indisponible. En l’absence de tels résultats, la description du produit ne permet pas de déduire son degré d’autonomie ni son taux d’erreur.
Les organisations auraient intérêt à commencer par des tâches circonscrites et réversibles. Si un agent prépare une proposition, une personne peut la vérifier avant son envoi ; s’il modifie des données ou déclenche une opération, le test doit prévoir des limites et une procédure de retour en arrière. Cette approche permet de mesurer si l’automatisation fait gagner du temps, sans confondre la capacité à enchaîner des étapes avec l’autorisation de les exécuter.
Mémoire et continuité entre les sessions
La continuité du contexte entre les sessions figure parmi les capacités associées à North 2 dans les informations disponibles. Faute de documentation opérationnelle suffisante, le terme « mémoire » peut recouvrir plusieurs comportements : conserver des préférences, retrouver des données d’une conversation antérieure ou maintenir l’état d’un flux. Ces usages ne sont pas équivalents et impliquent des exigences différentes en matière de confidentialité, de contrôle et de fiabilité.
Pour évaluer cette capacité, il faut obtenir des réponses précises : quelles informations sont conservées, pendant combien de temps, où elles sont stockées, qui peut les consulter et si elles sont réutilisées pour d’autres tâches. Il importe également de savoir si une personne chargée de l’administration peut examiner, corriger et supprimer le contexte, et ce qui se passe après une demande de suppression. Les éléments disponibles ne précisent pas ces points ; il est donc impossible de confirmer comment la mémoire est mise en œuvre ni quelles options de contrôle sont offertes aux clients.
Un test pratique devrait utiliser des données synthétiques ou des informations non sensibles. On démarre une tâche, on termine la session, puis on vérifie quel contexte le système retrouve. On tente ensuite d’effacer cette donnée et on contrôle qu’elle ne réapparaît ni lors des sessions suivantes ni dans des journaux auxquels elle ne devrait pas être accessible. Le test doit être répété avec différents utilisateurs et niveaux d’autorisation : une mémoire utile à la continuité peut aussi devenir une source d’exposition si l’isolation entre les comptes est défaillante.
Vérifications pour tester la mémoire
Avant de connecter des données réelles, il convient de définir les éléments à tester et les résultats considérés comme acceptables.
- 01Utiliser des informations synthétiques et définir le contexte que le système devrait conserver.
- 02Répéter la tâche lors d’une autre session et consigner les données retrouvées par l’agent.
- 03Vérifier que le contexte est isolé entre des utilisateurs disposant d’autorisations différentes.
- 04Demander la suppression d’une donnée et vérifier à nouveau si elle réapparaît.
- 05Examiner les journaux disponibles et documenter tout écart entre ce qui était attendu et ce qui a été observé.
Coûts, autorisations et modèles externes
Cohere inclut la gouvernance des coûts parmi les composantes de North 2. Cette description ne suffit pas à déterminer si les budgets constituent des plafonds stricts ou de simples alertes, ni à quel niveau ils peuvent être configurés : agent, personne, équipe ou flux. Elle ne précise pas non plus ce qui se produit lorsqu’un seuil est atteint, si une tâche s’interrompt automatiquement ou si elle peut continuer à générer des coûts. Ces différences sont essentielles pour savoir si un contrôle prévient réellement les dépenses ou se contente de les signaler.
Une évaluation devrait fixer de petits budgets dans un environnement de test, approcher le plafond puis le dépasser, et observer le comportement du système. Il faut également vérifier si les coûts sont attribués à une tâche ou à un utilisateur, si les administrateurs peuvent modifier le budget et si ces modifications sont consignées. La politique écrite et le comportement réel doivent correspondre ; dans le cas contraire, le plafond ne devrait pas être considéré comme une mesure de protection effective.
Les informations disponibles évoquent également la connexion à des modèles d’autres fournisseurs, mais les éléments vérifiables ici n’identifient ni liste précise de modèles ni conditions de compatibilité. Affirmer qu’une plateforme prend en charge différents modèles ne permet pas de savoir si toutes les fonctions sont disponibles avec chacun d’eux, quelles données sont transmises au fournisseur ni qui est responsable de leur conservation ou de leur utilisation. Les entreprises devraient vérifier ces points pour chaque intégration, sans présumer que la compatibilité est universelle.
La sécurité exige le même niveau de précision. Pour déterminer si un agent peut être utilisé en production, il faut connaître la manière dont les autorisations sont attribuées, les outils qu’il peut appeler, les actions nécessitant une approbation et les journaux conservés. Les informations disponibles ne permettent pas de confirmer ces détails pour North 2. Il n’est donc pas possible d’affirmer que ses contrôles éliminent le risque d’actions non autorisées.
Questions à poser avant un projet pilote
| Domaine | Question de vérification | Éléments à demander |
|---|---|---|
| Coûts | Le budget interrompt-il le flux une fois le plafond atteint ? | Un test encadré et un relevé de la consommation. |
| Autorisations | Quelles actions chaque agent peut-il exécuter ? | Une configuration exportable et un test avec différents rôles. |
| Mémoire | Quel contexte est conservé et comment le supprimer ? | La politique de conservation et un test de suppression. |
| Modèles externes | Quels modèles sont disponibles et quelles données reçoivent-ils ? | La liste des intégrations et les conditions applicables à chacune. |
| Audit | Quelles actions sont consignées et qui peut accéder aux journaux ? | Des exemples de journaux et les règles d’accès. |
Ce qu’il reste à vérifier pour évaluer North 2 en production
Les informations disponibles permettent de décrire l’objectif du produit : réunir des agents, des flux et des contrôles destinés aux entreprises dans une même plateforme. Elles ne permettent pas de mesurer sa fiabilité, de vérifier la continuité du contexte ni de déterminer si les plafonds de dépenses et les autorisations sont effectivement appliqués. Elles ne fournissent pas non plus de résultats comparatifs ni de tests indépendants permettant d’évaluer ses performances face à d’autres solutions dans des conditions équivalentes.
Avant un déploiement à grande échelle, une organisation devrait demander une documentation technique correspondant à sa configuration et mener un projet pilote à partir de critères de réussite définis. Ceux-ci pourraient inclure la proportion de tâches menées correctement, la fréquence des interventions humaines, les erreurs d’autorisation, la consommation par flux et le respect des politiques de conservation. Les résultats devraient être examinés avec différents utilisateurs, types de tâches et scénarios d’échec ; un seul exemple réussi ne constitue pas une preuve suffisante.
La conclusion prudente reste limitée : North 2 est présenté comme une plateforme d’agents d’entreprise dotée de contrôles des coûts et de la sécurité, et les informations disponibles décrivent les flux en plusieurs étapes et la continuité du contexte comme des éléments de l’offre. L’efficacité réelle des contrôles, la mise en œuvre de la mémoire et la compatibilité précise avec des modèles externes ne sont pas établies. Il faut confirmer ces aspects à l’aide d’une documentation applicable et de tests reproductibles avant de considérer l’annonce comme une garantie de comportement en production.
Questions ouvertes
- Quelles fonctions sont accessibles à l’ensemble des clients et lesquelles dépendent d’une configuration, d’une formule ou de leur disponibilité.
- Quelles données constituent la mémoire entre les sessions, combien de temps elles sont conservées et comment demander puis vérifier leur suppression.
- Si les plafonds de dépenses interrompent réellement un agent ou un flux, et à quel niveau ils peuvent être définis.
- Quels modèles tiers sont compatibles, quelles fonctions diffèrent selon le modèle et quelles conditions encadrent le traitement des données.
- Quelle documentation technique et quels tests indépendants sont disponibles sur les autorisations, les journaux, la sécurité et la fiabilité en production.
Poursuivre l’exploration
Sources consultées
Corrections et transparence
Si vous repérez une information incorrecte ou obsolète, envoyez-nous la page et la source à vérifier.
Proposer une correction