Sécurité et protection des données
Développement et tests sécurisés
Comment les modifications de Telonic sont effectuées, revues, testées et mises en production, comment les vulnérabilités sont gérées, et ce qui est attendu des personnes qui développent et exploitent le produit.
Sur cette page
La sécurité d’un produit dépend autant de la manière dont il est modifié que de la manière dont il a été conçu à l’origine. Chaque modification de Telonic, qu’elle porte sur la plateforme ou sur vos agents IA, est revue et testée avant sa mise en production, dans un environnement distinct de votre environnement de production. Les modifications du comportement de l’agent sont en outre testées sur des conversations issues de votre secteur, et aucun changement de modèle ou de fournisseur n’atteint vos clients sans votre approbation. Cette page décrit comment les modifications sont effectuées et mises en production, comment les failles sont détectées et corrigées, et les exigences qui s’appliquent aux personnes qui réalisent ce travail.
Le parcours d’une modification jusqu’à votre déploiement
Chaque modification suit le même parcours, et chaque étape est consignée.
| Étape | Ce qui se passe |
|---|---|
| 1. Consignée | La modification est effectuée dans le système de gestion de versions (un système qui consigne chaque modification, son auteur et sa date), de sorte que chaque modification peut être retracée et annulée |
| 2. Revue | Un autre ingénieur revoit la modification avant qu’elle puisse être fusionnée |
| 3. Vérifiée | Des tests automatisés et des contrôles de sécurité s’exécutent sur la modification, y compris la recherche de vulnérabilités connues dans les composants qu’elle utilise |
| 4. Testée pour votre secteur | Les modifications qui affectent le comportement de l’agent passent par des suites de tests de non-régression (des ensembles de tests qui confirment que le comportement existant fonctionne toujours) construites à partir des conversations de votre secteur |
| 5. Mise à l’essai | La modification s’exécute dans un environnement de test, distinct de votre environnement de production, avant qu’un client ne la voie |
| 6. Approuvée | Les modifications qui nécessitent votre approbation, y compris tout changement de modèle ou de fournisseur, restent en attente de celle-ci |
| 7. Mise en production | La modification est mise en production et peut être annulée si nécessaire |
Tester l’agent, pas seulement le code
Les tests de code confirment que le logiciel fonctionne. Ils ne peuvent pas vous dire si l’agent traite toujours correctement une réserve contestée ou un réacheminement dans le respect des règles tarifaires. Pour cela, Telonic tient à jour des jeux d’évaluation pour chaque secteur : des conversations de test tirées de schémas de conversation réels, chacune notée au regard de ce qu’est un résultat correct dans ce secteur. Des suites de tests de non-régression construites à partir de ces jeux s’exécutent avant chaque nouvelle version.
Un nouveau modèle de langage (le modèle d’IA qui comprend la conversation et décide de la réponse) n’est adopté que s’il obtient sur le jeu de tests sectoriel des résultats au moins aussi bons que le modèle qu’il remplace. La simulation de conversations (le test de l’agent sur des scénarios réalistes avant la mise en production, le moment où il commence à prendre en charge de vrais clients) est configurée lors de la mise en œuvre. Voir Tests avant chaque nouvelle version.
Détecter et corriger les failles
| Pratique | Fonctionnement |
|---|---|
| Gestion des dépendances | Les composants logiciels tiers sont inventoriés et tenus à jour |
| Gestion des vulnérabilités | Les composants et l’infrastructure sont analysés afin de détecter les vulnérabilités connues. Les correctifs sont classés par ordre de priorité selon la gravité, les vulnérabilités les plus graves étant corrigées en premier |
| Tests d’intrusion indépendants | Des testeurs indépendants réalisent des tests d’intrusion (une attaque simulée et autorisée, destinée à détecter les failles) au moins une fois par an et après les modifications majeures. Les constats sont corrigés par ordre de gravité, et un résumé est mis à la disposition de votre équipe sécurité sous accord de confidentialité |
| Gestion des secrets | Les identifiants et les clés sont conservés dans un coffre-fort de secrets (un service conçu pour conserver les identifiants en toute sécurité), jamais dans le code ni dans des fichiers de configuration |
Contrôle des modifications avec vous
Les modifications suivent un processus documenté de contrôle des modifications. On vous informe avant toute modification importante de votre déploiement, et les modifications du comportement de vos agents IA, comme les limites, les sujets ou les règles d’escalade, sont mises en production selon le processus décrit dans Comment les modifications sont mises en production. Chaque modification d’un agent est consignée, ce qui vous permet de voir ce qui a changé, quand, et qui l’a approuvée.
Les personnes qui développent et exploitent Telonic
Les ingénieurs qui peuvent accéder aux environnements des organisations clientes passent avec succès une vérification des antécédents avant de recevoir cet accès. Chaque personne chez Telonic suit une formation à la sécurité à son arrivée, puis à intervalles réguliers. Les accès sont retirés lorsqu’une personne change de rôle ou quitte l’entreprise.
L’accès aux déploiements des organisations clientes est réservé à des ingénieurs désignés, qui travaillent depuis les Émirats arabes unis ou depuis le pays que vous choisissez. Cet accès est accordé pour une durée limitée, et chaque accès est journalisé. Voir Contrôle d’accès et authentification unique.
En pratique
Le voyagiste Nakhla Travel utilise des agents IA pour les réservations et les modifications.
- Un modèle de langage plus récent devient disponible dans la région de Nakhla Travel. Un ingénieur consigne la modification dans le système de gestion de versions, et un second ingénieur la revoit.
- Les tests automatisés et les contrôles de sécurité sont concluants. La suite de tests de non-régression pour le voyage s’exécute : demandes de réservation, modifications dans le respect des règles tarifaires, et messages concernant les retards et les annulations.
- Le nouveau modèle obtient des résultats au moins aussi bons que l’ancien. Les résultats sont communiqués au responsable des opérations de Nakhla Travel.
- La modification s’exécute dans l’environnement de test, où l’équipe de Nakhla Travel teste ses propres cas difficiles.
- Nakhla Travel approuve la modification, qui est mise en production. La trace consignée montre ce qui a changé, quand et qui l’a approuvée.
Ce que votre équipe contrôle
- L’approbation de tout changement de modèle ou de fournisseur avant sa mise en production.
- L’approbation des modifications des limites, des sujets et des règles d’escalade de vos agents IA, au moyen des contrôles que détient votre équipe.
- La demande du résumé du dernier test d’intrusion, sous accord de confidentialité.