Comprendre le besoin avant de brancher un agent.

Sécurité et gouvernance : les principes

Ce qui vaut pour chaque projet, écrit une fois. Les détails d’implémentation sont dans chaque réalisation ; les données et sous-traitants sur leur page.

• Permissions minimalesDes identifiants dédiés et des permissions limitées aux outils et aux données nécessaires, selon les possibilités des outils intégrés.Risque évité Un agent qui prépare des devis n’a aucune raison de pouvoir supprimer des factures.
• Accès et environnements séparésUn environnement de test avec des données fictives, un environnement de service avec les vraies, et des accès distincts pour chacun.Risque évité Un test qui envoie un vrai e-mail à un vrai client.
• Validation humaine sur les actions sensiblesEnvoyer, payer, supprimer, créer un accès : une personne habilitée valide avant, avec le contexte pour décider vite.Risque évité Une relance partie à tort, un devis envoyé avec un mauvais montant.
• Traçabilité des actions et des erreursChaque exécution laisse une trace : qui a déclenché quoi, quand, avec quel outil et quel résultat.Risque évité Une erreur découverte trois semaines plus tard, sans savoir d’où elle vient.
• Échecs prévus, reprise écriteUn appel d’outil qui échoue, une réponse hors des attentes : arrêt propre, alerte, et une procédure de reprise rédigée à l’avance.Risque évité Des demandes perdues en silence pendant une panne.
• Évaluation des réponses et des comportementsUn jeu de cas de référence, rejoué avant la mise en service et après chaque changement de modèle, d’outil ou de documents.Risque évité Un assistant qui répond avec assurance à côté de la question, sans que personne ne s’en aperçoive.
• Transparence sur l’hébergement, les données et les sous-traitantsOù tournent les modèles, où vont les données, qui y accède : écrit avant de commencer, sur la page Données et sous-traitants.Risque évité Des documents confidentiels envoyés à un service dont personne n’a lu les conditions.

Aucune de ces mesures ne rend un système infaillible : un modèle peut se tromper, un outil peut tomber. Elles servent à ce qu’une erreur soit vue, arrêtée et reprise, et à ce que vous gardiez la main.

Le détail de vos données est sur la page Données et sous-traitants.

Quatre architectures que nous utilisons souvent

Le détail technique, pour la personne qui s’en occupe chez vous.