Agent One : description détaillée de la solution
Agent One est une plateforme logicielle qui permet à une institution de déployer des agents d'intelligence artificielle sous sa propre autorité. Elle s'installe dans l'infrastructure du client, peut fonctionner sans aucune connexion à Internet, et réunit en un seul produit l'exécution des agents, leur administration et leur surveillance de sécurité. Agent One est édité par Ticanalyse.
1. Vue d'ensemble
Un agent d'IA ne se contente plus de répondre. Il lit des documents, appelle des services, exécute des commandes. Il dispose d'accès comme un collaborateur, mais il agit à partir d'instructions en langage naturel, qui peuvent être détournées. Agent One traite chaque agent comme un collaborateur à encadrer : un périmètre, des droits, une charte, un supérieur hiérarchique et une trace de tout ce qu'il fait.
La plateforme repose sur trois fonctions.
• Orchestrer : Agent One exécute chaque agent dans son propre environnement isolé, sur les canaux que l'institution autorise.
• Administrer : rôles, authentification forte, charte d'usage, politiques d'outils et de fournisseurs, coffre de secrets, coupures immédiates.
• Superviser : un centre d'opérations de sécurité (SOC) dédié aux agents observe, détecte, alerte et répond, sous décision humaine.
Cinq principes techniques traversent tout le produit.
• Fermé en cas de doute. Quand un contrôle ne peut pas être vérifié, l'accès est refusé. Un certificat illisible empêche le démarrage. Une charte dont l'acceptation ne peut être lue bloque l'agent.
• L'humain décide des mesures lourdes. Aucune suspension d'agent n'est automatique. Une demande d'approbation expirée vaut refus.
• La visibilité est mesurée. Chaque indicateur affiche sa couverture. Un capteur en panne donne « inconnu », jamais « zéro incident ».
• La décision se prend au plus près de l'action. Les modèles autorisés et les destinations permises sont vérifiés au moment de l'appel, dans les composants qui accompagnent chaque agent.
• La preuve plutôt que la promesse. Journal d'audit chaîné et vérifiable ; la consultation même des données de sécurité est journalisée.
2. Architecture
Agent One s'organise en trois plans séparés : le plan de gouvernance décide, le plan d'exécution agit, le plan de supervision observe.
L'agent n'a aucune route directe vers l'extérieur. Il ne joint le modèle que par son proxy d'accès au fournisseur, et le reste du monde que par son proxy de sortie. Tout ce qui passe laisse une trace, lue par le SOC hors du chemin critique.
3. Orchestrer : le parc d'agents
Chaque agent tourne dans un environnement qui n'appartient qu'à lui. Un agent compromis n'atteint pas ses voisins, parce que le cloisonnement est physique et pas seulement logique.
L'agent lui-même ne détient jamais la clé du modèle. Il ne connaît que son proxy. Si l'organisation coupe un fournisseur, la clé est retirée du proxy et l'agent ne peut plus rien appeler.
Le provisionnement est fermé : un agent qui ne serait pas rattaché à un réseau interne est refusé à la création. Le nombre d'agents est plafonné par la licence de l'organisation ; au-delà, la création échoue.
Organisations, départements, groupes
L'organisation est l'unité de cloisonnement : une institution, une filiale ou une direction autonome, avec ses propres données, secrets, charte, fournisseurs et règles de sécurité. C'est la frontière de sécurité. Le département est une étiquette administrative de l'agent, qui sert à la ventilation, aux tableaux de bord et à la portée d'une règle. Le groupe rassemble des utilisateurs qui partagent une politique effective : c'est le bon niveau pour raisonner sur les habilitations.
Une même plateforme peut héberger plusieurs ministères, ou plusieurs filiales d'un groupe bancaire, sans qu'aucune entité voie les données d'une autre. L'organisation est toujours déduite de l'identité authentifiée, jamais d'un paramètre de requête.
Familles d'outils et niveaux de risque
Les capacités d'un agent sont regroupées en familles, chacune classée par niveau de risque. L'administrateur d'organisation accorde les familles une à une.
Le niveau moyen couvre la recherche et la navigation web. Le niveau élevé couvre les fichiers, le navigateur automatisé et les secrets. Le niveau critique couvre le terminal, l'exécution de code, les tâches planifiées et la délégation à d'autres agents.
Un outil utilisé hors des familles accordées déclenche une alerte du SOC (règle AOS-3001). Le niveau de risque des familles alimente aussi le score de risque de l'agent.
Canaux
Un agent peut être joint par conversation web, application mobile, SMS, courriel ou voix. Chaque canal est ouvert ou fermé explicitement par l'organisation ; un canal non ouvert est refusé. Le canal SMS chiffré s'adresse aux équipes de terrain en zone peu connectée.
Tâches planifiées et délégation
Un agent peut exécuter des tâches programmées et confier des sous-tâches à d'autres agents. Ces deux capacités sont classées critiques. Elles passent par les mêmes proxys, les mêmes politiques et la même supervision que le reste.
4. Administrer : identités, règles et coupures
Agent One donne à chaque responsable exactement les droits de sa fonction, et permet d'arrêter n'importe quel usage en une action.
Rôles et permissions
• Super-administrateur de plateforme, sur toute la plateforme : organisations, fournisseurs et clés, décisions les plus sensibles.
• Opérateur de plateforme, en exploitation sur toute la plateforme : santé des environnements, supervision agrégée, sans pouvoir de réponse par défaut.
• Administrateur d'organisation, sur son organisation : utilisateurs, agents, charte, politiques, règles de sécurité, réponse aux alertes.
• Auditeur d'organisation, sur son organisation en lecture seule : journaux, alertes et supervision, sans aucun pouvoir d'action.
• Utilisateur final, sur son propre agent, sans accès aux surfaces d'administration.
Authentification
• Second facteur par code temporaire TOTP (RFC 6238), compatible avec les applications d'authentification courantes. Il est obligatoire pour les trois rôles d'administration. Huit codes de secours sont fournis ; un code par SMS est possible via une passerelle configurable.
• Fédération d'identité OpenID Connect avec l'annuaire de l'institution. Chaque émetteur est rattaché à une seule organisation. Les rôles de plateforme ne s'obtiennent jamais par fédération, et une revendication de l'annuaire ne promeut jamais un compte existant. La création de compte à la volée est désactivée par défaut. Le secret client est chiffré au repos. Toute impasse de résolution refuse la connexion.
Charte d'usage
Chaque organisation publie sa charte d'usage de l'IA. Tant qu'un utilisateur n'a pas accepté la version en vigueur, il ne peut pas utiliser son agent. Une nouvelle version invalide toutes les acceptations antérieures. Publications et acceptations sont journalisées, et la charte s'exporte en PDF. Si l'état d'acceptation ne peut pas être lu, l'accès est refusé.
Instructions de cadrage et politiques
L'organisation définit les instructions communes à ses agents et ses politiques. Ces éléments sont versionnés et validés à l'écriture. Une analyse d'impact est disponible avant publication.
Coffre de secrets
Les identifiants dont un agent a besoin (clés d'API, mots de passe applicatifs) sont rangés dans un coffre chiffré avec une clé propre à chaque organisation. Chaque écriture, lecture, liste ou révocation est journalisée. Un secret lu par un agent est masqué dans la réponse affichée et n'atteint jamais les tables du SOC. Le composant de coffre de chaque agent s'authentifie par un certificat client émis par l'autorité interne.
Fournisseurs et modèles d'IA
Agent One se branche sur les modèles par dix profils compatibles avec le standard d'API d'OpenAI. L'un d'eux est un point d'accès personnalisé pour raccorder le modèle hébergé sur le serveur d'inférence de l'institution.
• La liste des modèles autorisés est vérifiée à chaque appel, dans le proxy de l'agent. Un modèle hors liste est refusé et signalé.
• La localisation de chaque fournisseur est déclarée : souverain, sur site ou externe. Une règle du SOC détecte toute requête vers une localisation interdite.
• La consommation est suivie en jetons. La plateforme n'affiche aucune estimation de coût, pour ne jamais présenter un chiffre invérifiable.
Une suspension posée par la plateforme ne peut être levée que par la plateforme. Si une réactivation échoue, l'état revient à « suspendu ». Si un agent refuse de s'arrêter lors d'une suspension d'organisation, l'organisation reste suspendue et l'agent en cause est nommé dans le journal.
5. Superviser : le SOC IA
Le SOC de Agent One observe ce que font les agents : les outils qu'ils appellent, les modèles qu'ils sollicitent, les destinations qu'ils contactent, les secrets qu'ils lisent. Il a été conçu pour les agents d'IA dès le départ, pas adapté d'un SOC classique.
Doctrine
1. Il exploite des traces opérationnelles et ne lit jamais le raisonnement interne des modèles.
2. Un capteur muet n'est jamais « aucun constat » : si une source manque, le résultat est « inconnu ».
3. Le contenu des échanges n'est jamais stocké en clair. Seules une empreinte et une longueur sont conservées ; le stockage du contenu est une option chiffrée, avec une clé propre à l'organisation.
4. Le SOC n'est pas dans le chemin critique des réponses. Si sa file sature, la perte est comptée et affichée, la conversation n'est jamais ralentie.
5. Une panne du SOC n'est pas une panne de l'IA : le service continue et le trou de visibilité est affiché.
6. Chaque organisation démarre en mode observation (SHADOW) : le SOC mesure et alerte, sans agir.
7. Aucune suspension d'agent n'est automatique.
Fonctionnement technique
Le SOC est dans une base dédiée avec ses propres rôles. La table d'événements sert à la fois de journal durable et de bus de traitement : pas de file de messages ni de moteur de recherche supplémentaire à exploiter. Sans configuration valide, le SOC se déclare désactivé plutôt que de se replier sur une autre base. Le journal est immuable : la base refuse modifications et suppressions, et la purge ne se fait que par partitions mensuelles, avec un audit écrit avant toute destruction.
La lecture des journaux prouve sa continuité à chaque passage : même fichier, non tronqué, empreintes de la première et de la dernière ligne inchangées. Toute rupture produit un événement de trou de télémétrie. Chaque capteur affiche son état (actif, dégradé, indisponible, non instrumenté), et l'écran Couverture dit au RSSI, à tout instant, ce que le SOC ne voit pas.
Les règles de détection
Le catalogue natif compte des règles réparties en sept familles. Chaque règle est adossée à une source réelle.
• Instructions: marqueur d'injection dans le résultat d'un outil, accès aux instructions système.
• Données: lecture de fichier ou de secret suivie d'une sortie vers un hôte tiers, classée critique ; volume sortant anormal.
• Outils: outil hors des familles accordées, commande de terminal destructive, boucle sur un outil.
• Identité: refus d'autorisation répétés, activité juste après une action d'administration sensible.
• Modèles et fournisseurs: modèle hors liste, requête vers une localisation interdite, dépassement de seuil de jetons.
• Comportement: nombre anormal d'événements dans une exécution.
• Réseau: rafale de connexions refusées, sortie hors de la liste par défaut.
Modes et passage en application
Chaque règle est désactivée, en surveillance, en alerte ou en application. Le plus restrictif l'emporte : une organisation en observation voit ses règles en application ramenées à « action proposée ». Toutes les règles natives sont livrées en surveillance. Pour passer une règle en application, l'administrateur doit disposer d'une simulation de la règle sur l'historique réel de l'organisation, datant de moins de 24 heures, revalidée au moment du passage et jointe à l'audit. Il sait donc d'avance combien de fois elle se serait déclenchée.
Détection du Shadow AI
Un catalogue local et versionné reconnaît 48 fournisseurs d'IA tiers. Le SOC lit le journal du proxy de sortie et classe chaque tentative : refusée vers une IA du catalogue (gravité haute, alerte), autorisée vers une IA non retenue (moyenne), refusée vers un hôte non classé (information). La détection ne fait aucun balayage réseau, aucune résolution DNS, aucun téléchargement de liste.
Score de risque
Chaque agent reçoit un score en cinq niveaux. Il combine le risque des outils, les destinations contactées, la sévérité des règles déclenchées et l'historique d'alertes sur 30 jours. Un facteur inconnu n'est jamais compté comme zéro : il est exclu et la complétude s'affiche (« Risque 72/100 · couverture 3/5 sources »). Le score d'un agent est le maximum de ses exécutions, jamais la moyenne.
Alertes, incidents et réponse
• Les alertes sont dédupliquées par règle, agent et fenêtre de temps. Au-delà du plafond, le nombre exact d'alertes non créées est signalé. Chaque alerte garde la version de la règle et la couverture des capteurs au moment des faits.
• Les incidents sont ouverts par un humain. Le moteur de risque en propose, sans les créer.
• L'explorateur reconstitue chaque exécution : outils, appels au modèle, sorties réseau.
• L'écran Activité en direct reçoit les événements par flux serveur (SSE), avec reprise après coupure, et sans aucun contenu de conversation.
En mode actif, le moteur de réponse peut interrompre une exécution ou bloquer une requête au modèle. La suspension d'un agent exige toujours l'approbation d'un administrateur habilité, sur horloge serveur ; une demande expirée vaut refus. Le mode de l'organisation est relu sous verrou à l'instant de chaque action. Les données de sécurité sont conservées 90 jours par défaut, durée réglable par organisation.
6. Sécurité technique
La sécurité de Agent One repose sur des mécanismes que les équipes du client peuvent vérifier elles-mêmes. Chacun a un comportement défini pour le cas où il ne peut pas conclure.
Chiffrement des échanges internes
Les échanges entre la console et les environnements d'exécution passent en TLS 1.2 ou supérieur. Une autorité de certification interne, propre à chaque installation, émet les certificats. La console vérifie la chaîne et le nom du certificat présenté. Un environnement annoncé en clair hors de la machine locale est refusé. Un certificat incomplet empêche le démarrage, plutôt qu'un démarrage dégradé en clair.
Le composant de coffre de chaque agent dispose d'une identité cliente par certificat (mTLS). Entre la console et les environnements, l'authentification repose aujourd'hui sur TLS côté serveur et une clé d'API interne propre à chaque environnement.
Isolation réseau et contrôle des sorties
Chaque agent a son réseau interne, sans route vers Internet. Les composants d'administration sont sur un réseau de contrôle séparé. Toute sortie passe par le proxy de l'agent, qui applique :
• une liste d'autorisation exacte par hôte et port, sans caractère générique ;
• le refus des adresses IP littérales ;
• la journalisation de chaque verdict ;
• le verrouillage complet si son journal ne peut plus être écrit.
On n'autorise pas ce qu'on ne peut pas tracer.
Fonctionnement hors ligne
Agent One s'installe en environnement totalement déconnecté. Les ressources de l'interface sont intégrées au produit, sans réseau de distribution de contenu. Les dépendances sont embarquées dans les images, qui sont transférées puis vérifiées par empreinte à l'arrivée. L'installation se fait en trois temps : préparation sur une machine connectée, transfert, installation sur la machine isolée. Les fonctions qui dépendent d'un service externe (synthèse vocale en ligne, vérification des mises à jour) sont listées avec leur remplacement local, par exemple un serveur de synthèse vocale interne. Le modèle d'IA, hébergé sur le serveur d'inférence de l'institution, se raccorde par le point d'accès personnalisé.
Journal d'audit
• Ajout seul : la base refuse modifications et suppressions.
• Chaîné par organisation : chaque entrée contient l'empreinte SHA-256 de la précédente.
• Vérifiable : une fonction recalcule la chaîne et signale toute rupture.
• Données personnelles séparées : adresse IP et appareil sont hors de l'empreinte, et peuvent être purgés sans casser la chaîne.
• Consultations tracées : consulter une donnée de sécurité est journalisé avant qu'elle soit servie. Si l'audit est indisponible, rien n'est affiché.
Sont journalisés : les actes d'administration, les refus et suspensions, les opérations sur les secrets, les consultations de supervision, les actions du SOC avec la version de la règle, et les purges de données.
Protection des données
Le SOC ne stocke ni contenu en clair, ni secret, ni raisonnement interne. L'isolation entre organisations est doublée : contrôle applicatif et sécurité au niveau des lignes de PostgreSQL, avec des tests croisés entre organisations sur chaque route et chaque action.
Correspondance avec les référentiels
Une matrice informative relie les mécanismes de Agent One à ISO/IEC 42001 (articles 4 à 10 et annexe A) et au NIST AI Risk Management Framework 1.0. Elle indique pour chaque exigence le mécanisme qui peut servir de preuve, et sa limite. Ce n'est ni une certification ni une déclaration de conformité : elle aide l'organisation à constituer son propre dossier.
7. Expériences d'usage
Chaque acteur dispose de l'interface de sa responsabilité, et seulement de celle-là.
Les consoles
• Console Plateforme, pour le super-administrateur et l'opérateur : organisations, provisionnement, fournisseurs d'IA, licences, santé du parc, sécurité agrégée.
• Console Organisation, pour l'administrateur et l'auditeur d'organisation : utilisateurs, groupes, départements, agents, charte, politiques, coffre, canaux, consommation, rapport Shadow AI.
• Espace utilisateur, pour l'utilisateur final : conversation avec son agent, fichiers, historique, acceptation de la charte.
• Console SOC, pour les rôles habilités : vue d'ensemble, activité en direct, agents et scores, traces, alertes, incidents, règles, approbations, couverture.
Les interfaces sont rédigées en français rigoureux. Un état n'est jamais signalé par la seule couleur : texte, icône et bordure l'accompagnent. Les horodatages sont en temps universel, l'heure locale s'affiche au survol. Les actions sensibles demandent une confirmation explicite.
L'application mobile Android
• Conversation et voix : réponses affichées au fil de l'eau, mode vocal mains-libres avec reconnaissance et synthèse vocales, possibilité d'interrompre l'agent en parlant, protection contre l'auto-écoute. Interface en français, anglais et plus de douze autres langues.
• Approbations : quand un agent demande à utiliser un outil sensible, le collaborateur reçoit un dialogue qui montre l'outil, la commande et un badge de risque. Une validation biométrique peut être exigée à chaque autorisation. Si seule l'option de refus est proposée, l'application refuse. L'historique des décisions est stocké dans une base locale chiffrée.
• Validation des connexions : le téléphone peut approuver une connexion ouverte sur un navigateur, uniquement après déverrouillage biométrique.
• Appairage par QR code, sans saisie d'adresse ni de mot de passe de service.
• Canal SMS chiffré : une application compagnon permet de converser avec l'agent sans données mobiles, d'approuver un outil par réponse courte et de partager une position. Elle vise les équipes de terrain.
Les interfaces de programmation
• API d'exécution : lancer une exécution d'agent, suivre ses événements en flux (SSE), l'arrêter.
• API d'administration : opérations des consoles, protégées contre la falsification de requêtes intersites et journalisées.
• API SOC : lecture paginée des événements, alertes, incidents, règles et couverture ; flux temps réel.
• API Shadow AI : rapport par organisation, filtrable par période et gravité.
• API charte : état d'acceptation et acceptation.
Les contrats sont documentés en OpenAPI. Chaque route applique la même politique de rôles que les consoles, et chaque réponse du SOC indique sa couverture.
8. Déploiement et exploitation
La configuration de référence installe tout chez le client : le serveur d'application Agent One et le serveur d'inférence qui héberge le modèle. Aucune donnée et aucune inférence ne quittent l'institution.
Modes de déploiement
• Sur site (référence) : serveur d'application et serveur d'inférence dans le centre de données de l'institution.
• Hors ligne (air-gap) : la même installation, sans aucune connexion à Internet.
• Cloud privé : installation sur l'infrastructure privée choisie par l'institution.
Le socle est volontairement sobre : conteneurs, PostgreSQL 16, Rust, Python et JavaScript standard.
Livraison avec contrôle anti-dérive
Avant toute écriture sur le serveur de production, la chaîne de déploiement compare la configuration réelle (réseaux, images, conteneurs) à celle que déclare la version à livrer. En cas d'écart, elle s'arrête sans rien modifier et consigne l'écart. Sinon, elle sauvegarde puis bascule. Côté serveur, elle n'a accès qu'à une liste de commandes nommées. Les images sont construites hors production, puis chargées : la production ne reconstruit jamais une image.
Retour arrière
Chaque évolution sensible est livrée avec sa procédure de retour : sauvegardes, commandes exactes, vérifications. Les anciennes versions restent disponibles. Les migrations de base sont idempotentes, numérotées et appliquées avant le code qui en dépend.
Rotation des certificats
L'autorité interne vit 10 ans et se renouvelle par une procédure planifiée. Les certificats serveur des environnements vivent 90 jours et sont réémis automatiquement à moins de 30 jours de l'échéance. Les identités clientes du coffre suivent le même mécanisme, avec en plus une commande de renouvellement à la demande.
Une tâche hebdomadaire surveille les échéances. La bascule est atomique : une panne à mi-parcours laisse la paire précédente intacte. Les outils de surveillance ne lisent jamais une clé privée.
Pré-production et mise en service du SOC
Un environnement de pré-production isolé, avec sa propre base, permet de rejouer toute la suite de tests et de tester l'exploitation avant chaque mise en service. Le SOC s'active en sept étapes réversibles : base dédiée, migrations, raccordement de la console, validation des écrans, activation des capteurs, observation en mode SHADOW, puis passage en mode actif organisation par organisation, sur décision de son administrateur.
9. Fiche technique récapitulative
• Déploiement : sur site (serveur d'application et serveur d'inférence), hors ligne, cloud privé.
• Socle : conteneurs, PostgreSQL 16, Rust, Python, JavaScript standard ; images épinglées SHA-256.
• Cloisonnement : par organisation (données, secrets, charte, fournisseurs, règles) ; un environnement d'exécution par agent ; sécurité au niveau des lignes.
• Rôles : 4 niveaux d'administration et l'utilisateur final ; 11 permissions nommées.
• Authentification : TOTP (RFC 6238) obligatoire pour l'administration, 8 codes de secours, SMS optionnel ; OpenID Connect.
• Charte : versionnée, acceptation obligatoire, export PDF.
• Canaux : web, mobile Android, SMS chiffré, courriel, voix.
• Modèles : 10 profils compatibles API OpenAI dont un point d'accès personnalisé ; liste de modèles autorisés ; localisation déclarée ; suivi en jetons.
• Coupure : 5 niveaux (fournisseur, organisation, utilisateur, agent, outil).
• Chiffrement : TLS 1.2+, autorité interne, identité cliente par certificat pour le coffre.
• Réseau : réseau interne par agent, sortie unique par proxy, liste d'autorisation exacte, IP littérales refusées.
• Secrets : coffre chiffré par organisation, accès journalisés, masquage.
• Audit : ajout seul, chaîné SHA-256 par organisation, vérifiable.
• SOC : 5 capteurs, 24 règles en 7 familles, observation par défaut, score de 0 à 100 avec complétude, suspension sur approbation humaine, flux SSE, rétention de 90 jours par défaut.
• Shadow AI : catalogue local de 48 fournisseurs, 3 niveaux de gravité.
• Certificats : autorité 10 ans, certificats 90 jours, réémission à moins de 30 jours.
• Référentiels : matrice informative ISO/IEC 42001 et NIST AI RMF 1.0.
