Annexe B. Mesures techniques et organisationnelles (art. 32 du règlement (UE) 2016/679)

Préambule

La présente Annexe décrit les mesures techniques et organisationnelles que CodeDesign S.r.l. (ci-après le « Prestataire ») adopte au sens de l'art. 32 du règlement (UE) 2016/679 pour garantir un niveau de sécurité adapté au risque dans le traitement des données à caractère personnel effectué pour le compte du Client.

Les mesures sont décrites par fonction et par effet. Le Prestataire n'indique pas de détails de mise en œuvre, de dénominations de systèmes internes, d'adresses, de composants ou de paramètres de configuration dont la divulgation réduirait l'efficacité des mesures elles-mêmes. Des informations complémentaires sont mises à la disposition du Client selon les modalités et dans les limites de l'art. 4.8 de l'Annexe A.

La présente Annexe décrit l'état des mesures à la date de la version. Elle peut être mise à jour par le Prestataire à condition que le niveau global de sécurité ne soit pas réduit, conformément à l'art. 12.5 des Conditions et à la section 15 qui suit.

1. Organisation de la sécurité

1.1 Rôles. Le Prestataire a attribué de manière formelle les responsabilités suivantes :

• a) Responsable de la sécurité de l'information : évaluation des risques de sécurité, vérification de l'efficacité des mesures, proposition et vérification des actions correctives.
• b) Référent pour la protection des données à caractère personnel : coordination de la matière de la protection des données, qualification et gestion des violations sous l'angle juridique, tenue du registre des violations, relations avec l'autorité de contrôle, suivi de la boîte privacy@codedesign.it.
• c) Responsable de la gestion des incidents : prise en charge des signalements, confinement technique, collecte et conservation des preuves, reconstitution de la portée de l'événement, coordination de la restauration.
• d) Direction : décision sur les notifications à l'autorité de contrôle et sur les communications aux personnes concernées lorsque le Prestataire agit en qualité de responsable du traitement, approbation des ressources affectées aux actions correctives.

1.2 Délégué à la protection des données. Le Prestataire n'a pas désigné de délégué à la protection des données au sens de l'art. 37 du règlement, ayant estimé que les conditions n'en sont pas réunies. L'évaluation est réexaminée au moins une fois par an. Le point de contact demeure la boîte privacy@codedesign.it.

1.3 Système de management. Le Prestataire a engagé l'adoption d'un système de management de la sécurité de l'information conforme à la norme ISO/IEC 27001:2022 et le parcours de certification correspondant est en cours. À la date de la présente Annexe, la certification n'a pas été obtenue. Le Prestataire ne déclare pas être certifié et communiquera aux Clients son éventuelle obtention, en mettant à jour la présente Annexe.

1.4 Réexamen. Les mesures décrites dans la présente Annexe sont réexaminées au moins une fois par an, après chaque violation de données à caractère personnel classée à risque moyen ou élevé et après chaque modification importante de l'architecture du Service.

2. Contrôle des accès et authentification

2.1 Identité centralisée. L'accès à la plateforme s'effectue exclusivement au moyen d'un système centralisé de gestion des identités, distinct de l'application. Les identifiants des utilisateurs ne sont pas conservés par l'application.

2.2 Vérification de l'adresse de courrier électronique. La politique d'autorisation par défaut de toutes les interfaces applicatives exige, outre l'authentification, que l'adresse de courrier électronique de l'utilisateur soit vérifiée. L'accès est refusé à défaut de cette condition.

2.3 Authentification à deux facteurs. Un second facteur d'authentification est disponible au moyen d'un code à usage unique envoyé à l'adresse de courrier électronique de l'utilisateur, configurable sur le système d'identité.

2.4 Validation des sessions. Les jetons d'accès sont validés en profondeur : vérification du destinataire, vérification de l'émetteur par rapport à une liste explicite, vérification de la durée et de l'expiration, vérification de la signature avec refus des jetons non signés, tolérance limitée sur les horloges. Les résultats négatifs sont enregistrés avec le motif du refus, sans jamais enregistrer le jeton.

2.5 Clés d'accès applicatives. Les clés d'accès délivrées au Client pour l'usage automatisé du Service sont générées avec une entropie élevée, sont conservées au repos exclusivement sous forme d'empreinte cryptographique et sont affichées en clair une seule fois, au moment de la création. Une clé dépourvue de portées déclarées ne permet l'authentification sur aucun canal. Chaque clé peut être limitée à des Employés numériques déterminés. L'état et l'expiration des clés sont vérifiés à chaque utilisation.

2.6 Séparation des privilèges des clés. Une clé applicative ne peut en aucun cas obtenir des privilèges de plateforme, de système ou d'organisation, et elle est soumise à une liste explicite d'opérations toujours refusées, parmi lesquelles la gestion de l'abonnement, la modification des crédits et la gestion des quotas. Lorsqu'une requête porte à la fois l'identité d'un utilisateur et une clé applicative, le profil d'autorisation de l'utilisateur prévaut toujours.

2.7 Permissions granulaires et comportement fail-closed. L'autorisation est fondée sur des permissions atomiques résolues par le système, et non sur l'offre d'abonnement. Chaque interface déclare de manière explicite la permission requise et refuse l'accès à défaut de déclaration ou de permission. Aucun profil autre que l'administrateur de plateforme ne peut créer ou modifier des définitions de rôle, et ne peut donc s'attribuer des privilèges supérieurs à ceux qu'il détient.

2.8 Accès pour le compte d'un utilisateur. La fonction par laquelle le personnel du Prestataire opère pour le compte d'un Utilisateur du Client est réservée aux seuls profils expressément habilités, elle ne peut pas être activée sur la seule déclaration du demandeur, elle requiert des privilèges supérieurs pour opérer sur des profils administratifs et elle est consignée dans le journal d'audit, de même que les tentatives refusées.

2.9 Autorisations vers les services connectés. Les autorisations OAuth vers les services connectés par le Client sont obtenues au moyen du flux de code d'autorisation avec extension de preuve de clé (PKCE) et avec un paramètre d'état signé et vérifié par comparaison à temps constant. Le renouvellement des jetons s'effectue en flux unique avec verrou distribué.

2.10 Jetons à durée de vie courte. Les sessions des fonctions de transcription en temps réel et les sessions d'essai des agents vocaux utilisent des jetons à durée limitée, à usage unique pour les sessions d'essai, avec signature vérifiée. En l'absence de la clé de signature, aucun jeton n'est considéré comme valide.

2.11 Conservation des jetons côté client. Le portail du Client conserve le jeton d'accès exclusivement en mémoire, sans l'écrire dans le stockage local du navigateur. L'application pour appareils mobiles conserve les identifiants dans le coffre sécurisé du système d'exploitation et applique la déconnexion coordonnée avec effacement des clés. Les portails secondaires n'exposent aucun jeton au navigateur, la session étant maintenue côté serveur sous forme chiffrée.

3. Séparation des données entre Clients

3.1 Périmètre. L'unité de séparation est l'environnement applicatif de chaque Client. Chaque ressource, requête, identifiant et journal se rapporte à cet environnement, et l'appartenance de l'utilisateur à l'environnement est vérifiée à chaque requête.

3.2 Nature de la mesure. La séparation est réalisée au moyen de contrôles applicatifs explicites dans les services, complétés par une règle unique de vérification de l'accès appliquée comme défense en profondeur. Le Prestataire déclare avec transparence qu'il s'agit de contrôles applicatifs encadrés par des tests automatiques de non-régression et non d'une séparation structurelle au niveau du stockage des données.

3.3 Tests automatiques. L'intégration continue exécute, à chaque modification, des tests qui vérifient : que chaque interface déclare la permission requise, avec une liste explicite et motivée des seules exceptions admises ; qu'il n'est pas possible d'accéder à des ressources appartenant à d'autres Clients ; que les limitations des privilèges des clés applicatives sont respectées. L'échec de ces tests empêche l'intégration de la modification.

3.4 Suppression logique. Les entités principales du modèle de données font l'objet d'une suppression logique avec filtre global, de sorte qu'un enregistrement supprimé ne soit jamais restitué par les interrogations ordinaires.

3.5 Séparation des Employés numériques. Chaque Employé numérique du Client est exécuté dans un conteneur dédié, avec ses propres volumes de stockage, avec la base de connaissances montée en lecture seule et avec un espace de travail séparé. Le stockage local contenant les conversations, la mémoire et les transcriptions réside dans le volume de chaque conteneur.

3.6 Canal interne des Employés numériques. Les appels du conteneur vers les services centraux sont authentifiés au moyen d'un identifiant dérivé, vérifié par comparaison à temps constant et lié à l'identité de l'Employé numérique, avec contrôle de cohérence auprès du système d'orchestration et avec protection contre la substitution d'identité entre Employés numériques différents.

3.7 Séparation dans l'observabilité. Chaque interrogation portant sur les journaux et les traces techniques doit contenir la référence à l'environnement du Client, à défaut de quoi elle est refusée, et l'appartenance de l'utilisateur à cet environnement est vérifiée. Pour les profils non administratifs, les champs techniques susceptibles de contenir des fragments de contenu sont retirés des résultats.

3.8 Revendeurs. Les privilèges attribués à un revendeur ne s'exercent que sur les ressources liées au revendeur par une relation explicite enregistrée dans le système. La qualité de revendeur ne peut être modifiée que par l'administrateur de plateforme et la modification est consignée dans le journal d'audit.

4. Chiffrement

4.1 Chiffrement des données en transit

• a) Toutes les communications entre les clients et la plateforme s'effectuent sur un canal chiffré avec le protocole TLS, avec redirection obligatoire du trafic non chiffré en dehors des environnements de développement.
• b) Les métadonnées du système d'identité sont récupérées exclusivement sur un canal chiffré.
• c) Les liens temporaires par lesquels les fichiers sont mis à disposition sont émis en lecture seule, exclusivement sur un canal chiffré, avec une expiration n'excédant pas une heure.
• d) Les connexions aux serveurs de messagerie entrante et sortante configurés par le Client s'effectuent sur un canal chiffré, avec négociation protégée.
• e) Le courrier consulté par l'application pour appareils mobiles est transmis exclusivement sur un canal chiffré avec vérification du certificat du serveur, sans aucune dérogation : un certificat non valide entraîne le refus de la connexion.
• f) La politique d'accès depuis des origines différentes ne permet pas la transmission d'identifiants de session, de sorte qu'aucun cookie ne puisse être envoyé depuis une origine tierce.

4.2 Chiffrement applicatif des données au repos

• a) Le Prestataire applique un chiffrement applicatif avec l'algorithme AES 256 bits en mode GCM, avec enveloppe versionnée, vecteur d'initialisation aléatoire et tag d'authentification. Une clé dont la longueur n'est pas conforme est refusée à l'usage et un déchiffrement non abouti génère une erreur sans jamais restituer la donnée.
• b) Sont protégés par ce chiffrement : les identifiants et les clés d'accès aux services configurés par le Client, les identifiants des boîtes aux lettres et des flux de travail, les secrets de signature des canaux et des webhooks, les identifiants et les jetons des connecteurs activés par le Client, les chaînes de connexion aux stockages documentaires du Client, ainsi que les transcriptions, les listes des participants et les résultats des réunions traitées par l'application pour appareils mobiles.
• c) Précision de transparence. Le chiffrement applicatif visé à la lettre b) ne s'étend ni aux contenus des conversations de chat ni aux documents chargés dans les bibliothèques de connaissances, qui sont protégés par les contrôles d'accès décrits aux sections 2 et 3 et par le chiffrement au repos du stockage sous-jacent visé à l'alinéa 4.3.

4.3 Chiffrement au repos de l'infrastructure

Le chiffrement au repos des supports de stockage est fourni par les fournisseurs d'infrastructure selon leurs conditions de service. Le Prestataire ne déclare pas cette mesure comme vérifiée par lui-même et ne l'assume pas comme un engagement contractuel propre jusqu'à l'obtention de l'attestation écrite du fournisseur d'infrastructure cloud et du fournisseur du serveur dédié.

4.4 Sauvegardes

Les sauvegardes des Employés numériques sont chiffrées à la source, avant la transmission vers le stockage distant : sans la clé de chiffrement, les copies sont inutilisables.

5. Gestion des secrets

5.1 Stockage centralisé. Les identifiants et les secrets nécessaires à la fourniture du Service sont conservés dans un stockage dédié, organisé par portées séparées, la valeur étant chiffrée au moment de l'écriture conformément à l'alinéa 4.2.

5.2 Clé principale. La clé principale de chiffrement est unique, elle ne réside ni dans le code source ni dans les fichiers de configuration versionnés et elle est conservée dans le coffre à clés du fournisseur d'infrastructure cloud, d'où elle est mise à la disposition de l'application sous forme de paramètre protégé.

5.3 Résolution au moment de l'usage. Les secrets ne sont résolus qu'au moment où ils sont nécessaires et avec un comportement fail-closed : une référence qui ne se résout pas génère une erreur et ne produit jamais une valeur vide. Les configurations transmises aux Employés numériques ne contiennent que des références aux secrets, jamais les valeurs.

5.4 Impossibilité de restitution. Les valeurs des secrets ne sont jamais restituées par les interfaces de programmation de la plateforme : l'exclusion est imposée par construction par le sérialiseur des réponses et ne dépend pas de chaque développeur. Le coffre des secrets mis à la disposition du Client est en écriture seule : les valeurs saisies ne peuvent plus être relues.

5.5 Journaux. Les valeurs des secrets sont masquées dans les journaux techniques, y compris lorsqu'elles sont résolues au moment de l'usage, et n'apparaissent pas dans les journaux de démarrage des Employés numériques.

6. Enregistrement et surveillance

6.1 Journal d'audit des opérations administratives. Le Prestataire tient un journal des opérations administratives qui indique, pour chaque opération : la date et l'heure, l'auteur réel, l'éventuel sujet ayant opéré pour le compte d'un utilisateur, l'environnement et l'organisation concernés, la catégorie et le type d'action, l'objet concerné, les détails et l'adresse d'origine. Sont couvertes, entre autres, les opérations sur les rôles et les permissions, les utilisateurs et les appartenances, les crédits et les quotas, les domaines et les groupes, les concessions sur les ressources et les demandes d'assistance, ainsi que les accès pour le compte d'un utilisateur.

6.2 Accès au journal. La consultation du journal est protégée par une permission dédiée. La vue relative à un Client déterminé est toujours filtrée sur l'environnement de ce Client.

6.3 Conservation. Les entrées du journal d'audit sont conservées pendant 24 mois puis effacées automatiquement.

6.4 Précision de transparence. Le journal d'audit couvre les opérations administratives et de configuration. Le Prestataire ne déclare ni un journal immuable ni un journal des accès aux contenus des Clients.

6.5 Observabilité. La plateforme produit des traces, des métriques et des journaux techniques au moyen d'un système d'observabilité, enrichis de la référence à l'environnement du Client. L'accès est soumis aux contrôles de l'alinéa 3.7.

6.6 Contenus exclus des journaux. Les règles d'écriture du code interdisent l'enregistrement de secrets, de jetons et de contenus étendus des utilisateurs, et sont encadrées par la revue des modifications.

6.7 Alertes opérationnelles. Le Prestataire maintient des alertes automatiques sur les événements importants pour la continuité et pour la sécurité, parmi lesquels le résultat négatif des vérifications périodiques de restauration et le redémarrage répété des services, avec notification à une boîte suivie.

6.8 Page d'état publique. Le Prestataire publie une page d'état du Service, alimentée par des sondes internes et vers les fournisseurs en amont, avec des notifications par courrier électronique, un canal d'abonnement et des avis internes. Par choix de sécurité, la page n'expose ni le nom ni le nombre des Employés numériques des Clients.

7. Sauvegardes et continuité

7.1 Environnement des Employés numériques

7.1.1 Versions. Le stockage objet qui héberge les copies conserve les versions non courantes pendant 30 jours, en protection contre les suppressions accidentelles.

7.1.2 Vérification automatique. Une vérification automatique exécutée toutes les 6 heures effectue une restauration réelle d'un Employé numérique par rotation à partir du stockage distant et compare les empreintes cryptographiques des données restaurées. Un résultat négatif génère une alerte ; à intervalles réguliers, une confirmation du bon fonctionnement de la vérification elle-même est en tout état de cause générée.

7.1.3 Test de restauration. Le dernier test de restauration réel, mené avec perte simulée des volumes, a été réussi le 10 juillet 2026, avec un temps de restauration mesuré d'environ 15 minutes, l'identité des données restaurées vérifiée par empreinte cryptographique et le service réactivé dès la première tentative.

7.1.4 Périmètre. N'entrent pas dans le périmètre des sauvegardes, par choix documenté, les enregistrements des réunions captés au moyen du participant automatique, le code applicatif et les caches des espaces de travail.

7.2 Environnement de la plateforme cloud

Les sauvegardes de la base de données et du stockage des fichiers de la plateforme cloud sont celles prévues par les services gérés du fournisseur d'infrastructure. Le Prestataire ne déclare pas, à la date de la présente Annexe, d'objectifs de temps de restauration et de perte maximale de données pour cet environnement : les objectifs seront déclarés et assumés comme un engagement lorsque la configuration correspondante aura été vérifiée et documentée.

8. Conservation et effacement des données

8.1 Effacements automatiques. Le Prestataire procède aux effacements ou aux anonymisations automatiques suivants :

8.2 Conversations vocales. La conservation des conversations vocales est configurable par le Client pour chaque agent. Un traitement nocturne applique un double critère, en considérant à la fois l'échéance communiquée par le fournisseur vocal pour chaque conversation et le délai configuré par le Client, et applique le premier des deux qui expire. L'effacement entraîne la suppression effective du fichier audio du stockage et la mise à zéro de la transcription, du résumé, de l'analyse, du numéro de téléphone de l'appelant et de la référence à l'audio, avec une nouvelle tentative en cas d'erreur. Subsiste une ligne technique résiduelle dépourvue de données à caractère personnel, conservée à seule fin d'éviter les doublons lors de l'importation et de démontrer que la déclaration de nature artificielle a bien eu lieu.

8.3 Mode sans conservation. Le Client peut activer un mode dans lequel la conversation vocale est enregistrée dépourvue de contenu dès le moment de la captation.

8.4 Effacement sur action du Client. L'effacement d'un document entraîne la suppression du fichier du stockage, la suppression des index de recherche correspondants et la suppression logique de l'enregistrement. L'effacement d'une bibliothèque entraîne l'effacement des documents qu'elle contient. L'effacement d'un Utilisateur entraîne la suppression logique dans la plateforme et la suppression effective sur le système d'identité, avec inscription au journal d'audit.

8.5 Précision de transparence. Pour les conversations de chat et pour les documents des bibliothèques de connaissances, aucun délai automatique d'effacement n'est prévu : ils sont conservés pendant la durée du Contrat, peuvent être effacés sur action du Client conformément à l'alinéa 8.4 et sont effacés au terme du Contrat conformément à l'art. 10 de l'Annexe A.

8.6 Effacement au terme du Contrat. L'art. 10 de l'Annexe A s'applique intégralement, lequel régit le choix entre restitution et effacement, les délais de 60 et 90 jours et le blocage de l'accès pendant la période intermédiaire.

9. Développement sécurisé

9.1 Branches protégées et revue. Les branches principales du code n'acceptent des modifications que par une demande d'intégration soumise à revue. L'écriture directe n'est pas autorisée.

9.2 Vérifications automatiques. À chaque demande d'intégration, l'intégration continue exécute la restauration des dépendances, la compilation en configuration de publication et l'exécution de la suite de tests, avec des privilèges minimaux attribués à l'exécutant. Un contrôle dédié empêche l'intégration de modifications dépourvues de la documentation de l'impact pour l'utilisateur.

9.3 Publication sans identifiants statiques. La mise en production s'effectue au moyen d'une identité fédérée vers le fournisseur d'infrastructure, sans identifiants statiques mémorisés dans le système d'intégration continue. La nouvelle version est publiée sur un environnement d'essai et promue en production seulement après vérification, avec possibilité de retour immédiat à la version précédente.

9.4 Règles de codage encadrées par des outils automatiques. Le Prestataire utilise ses propres outils d'analyse statique, qui interdisent la gestion générique des exceptions dans les services, interdisent la suppression silencieuse des erreurs et imposent la protection des appels risqués. La construction manuelle des réponses d'erreur est empêchée à la compilation.

9.5 Tests de sécurité de non-régression. La suite comprend des tests dédiés portant sur : la couverture du contrôle des permissions sur chaque interface, l'impossibilité d'accéder à des ressources d'autres Clients, la liste des opérations refusées aux clés applicatives, l'affichage unique des clés, la limitation des clés à des Employés numériques déterminés, le chiffrement des données au repos, la conservation et l'effacement des conversations vocales, la vérification des signatures des webhooks, la protection contre les requêtes vers des ressources de réseau internes, l'usage de l'extension de preuve de clé et de l'état signé dans les autorisations, l'isolement de l'exécution des scripts et les fonctions de pseudonymisation.

9.6 Exécution isolée des scripts. Les scripts définis par le Client dans les automatisations sont exécutés dans un environnement isolé, dépourvu d'accès à des ressources externes et limité en profondeur de récursion, en mémoire, en temps, en nombre d'instructions et en durée des expressions de recherche.

9.7 Contrat d'erreur. Les réponses d'erreur restituées aux clients ne contiennent ni traces d'exécution ni détails internes : elles sont restituées sous un format normalisé avec un identifiant de corrélation utile à l'assistance.

9.8 Précision de transparence. Le Prestataire ne déclare pas, à la date de la présente Annexe, l'exécution automatique en intégration continue d'analyses des vulnérabilités des dépendances, de balayage des secrets ou d'analyse statique de sécurité du code de tiers.

10. Protection contre les abus et les usages impropres

10.1 Limitation de la fréquence des requêtes. Les interfaces applicatives sont protégées par des limites de fréquence, avec une réponse normalisée et l'indication du temps d'attente. Des politiques distinctes sont prévues pour le widget de conversation, avec une limite instantanée et un budget quotidien par Client, pour l'utilisateur authentifié et pour le trafic anonyme, ainsi que des règles configurables par chemin et par Client.

10.2 Limites de traitement. Les tâches exécutées en différé sont soumises à une limite de concurrence par Client, qui ne peut être dépassée. La consommation du Service est soumise à quota, avec un comportement fail-closed en cas de dépassement.

10.3 Validation de l'origine du widget. Le widget de conversation n'accepte les requêtes que depuis des origines déclarées et vérifiées. L'absence de l'origine entraîne le refus.

10.4 Intégrité des communications entrantes. Tous les webhooks reçus des fournisseurs externes font l'objet d'une vérification de la signature, par comparaison à temps constant. Pour le canal vocal, la vérification comprend le refus en l'absence du secret et une protection contre la réutilisation de la même requête fondée sur la référence temporelle.

10.5 Communications sortantes. Les webhooks envoyés vers les systèmes du Client sont signés, de sorte que le destinataire puisse en vérifier l'authenticité.

10.6 Protection contre les requêtes vers des ressources internes. Les adresses que la plateforme contacte à la demande du Client sont soumises à un contrôle qui refuse la requête lorsque ne serait-ce qu'une seule adresse résolue appartient à des espaces réservés, internes ou de service de l'infrastructure. Le contrôle est répété à chaque nouvelle tentative d'envoi.

11. Moyens de protection à la disposition du Client

11.1 Zone de résidence des données vocales. La sélection de la zone européenne du fournisseur vocal, avec effet sur les appels et sur les transcriptions de son propre environnement, est disponible pour les Clients de l'Offre Enterprise ; pour les autres offres s'applique la zone globale. Pour les abonnements vocaux partagés mis à disposition par le Prestataire, la zone globale s'applique en tout état de cause. Les fonctions réservées à l'Offre Enterprise sont disponibles lorsqu'elles sont prévues dans la proposition commerciale acceptée par le Prestataire, conformément à l'art. 2.3 des Conditions ; les offres sont décrites dans la grille tarifaire publiée à l'adresse https://evolus.ai/fr/tarifs.

11.2 Acheminement des requêtes vers les modèles et limitation des fournisseurs. Sont disponibles pour les Clients de l'Offre Enterprise, lorsqu'elles sont prévues dans la proposition commerciale acceptée par le Prestataire conformément à l'art. 2.3 des Conditions : la définition de la liste des fournisseurs d'inférence admis pour son propre environnement, qui est appliquée par le système et prévaut sur les préférences définies au niveau de chaque fonction ; l'acheminement européen des requêtes vers les modèles, au moyen du point de terminaison de l'Union européenne du service d'acheminement ; l'acheminement vers les seuls points de terminaison à conservation zéro. Pour les autres offres s'appliquent l'acheminement global et les fournisseurs d'inférence de la liste publiée sur la page des sous-traitants ultérieurs, à l'adresse https://evolus.ai/fr/sous-traitants.

11.3 Conservation des conversations vocales. Pour toutes les offres, le Client peut configurer le délai de conservation pour chaque agent vocal et peut activer le mode sans conservation, conformément aux alinéas 8.2 et 8.3.

11.4 Pseudonymisation et caviardage. La plateforme met à disposition des fonctions de pseudonymisation des données à caractère personnel et de caviardage des documents. Le caviardage des documents au format PDF est réalisé par rastérisation, de sorte que le texte caviardé ne soit plus présent dans le fichier produit. Un bloc de pseudonymisation est utilisable au sein des automatisations définies par le Client.

11.5 Protections non désactivables. Les Employés numériques appliquent des protections qui ne peuvent être ni désactivées par le Client ni contournées au moyen d'instructions, en matière de confirmation explicite de l'utilisateur avant les actions importantes, de vérification de l'identité du destinataire, de vérification de l'authenticité de l'expéditeur et de déclaration de nature artificielle. Le canal vocal applique en outre un ensemble de règles non désactivables protégeant les données à caractère personnel des salariés, les communications internes, les données économiques et les opinions.

11.6 Déclaration de nature artificielle. La déclaration de nature artificielle est réappliquée par le système sur les communications sortantes, elle ne peut pas être retirée par le Client et la preuve correspondante est conservée. Le Prestataire procède à une vérification périodique de conformité sur les communications générées.

11.7 Application pour appareils mobiles. L'audio des messages vocaux n'est pas conservé sur les systèmes du Prestataire au-delà du traitement, seule la mesure de la durée étant conservée aux fins de la consommation. L'audio des réunions enregistré sur l'appareil est placé dans une zone exclue des sauvegardes système. L'accès à l'appareil photo est exclu des permissions de l'application. Les demandes de permission déclarent expressément à l'utilisateur que le contenu transite par les systèmes du Prestataire et par le fournisseur d'intelligence artificielle.

12. Fournisseurs et sous-traitants ultérieurs

12.1 Sélection. Le Prestataire sélectionne les sous-traitants ultérieurs sur la base des garanties offertes en matière de protection des données et de sécurité de l'information, et conclut avec chacun d'eux un accord de traitement des données comportant des obligations non moins contraignantes que celles assumées envers le Client.

12.2 Liste publique. La liste des sous-traitants ultérieurs est publiée sous forme versionnée à l'adresse https://evolus.ai/fr/sous-traitants, avec l'indication de l'activité exercée, du pays d'établissement et de la base juridique du transfert, lorsqu'elle est applicable.

12.3 Variations. Les adjonctions et les remplacements sont communiqués au Client avec un préavis d'au moins 30 jours, avec droit d'opposition motivée, conformément à l'art. 5 de l'Annexe A.

12.4 Transferts. Les bases juridiques des transferts vers des pays tiers et les fonctions de réduction des transferts réservées à l'Offre Enterprise sont régies par l'art. 6 de l'Annexe A.

13. Gestion des incidents et des violations de données à caractère personnel

13.1 Procédure documentée. Le Prestataire maintient une procédure documentée de gestion des violations de données à caractère personnel, qui définit les canaux de détection et de signalement, les rôles et les responsabilités, les étapes opérationnelles avec les délais correspondants, les critères d'évaluation du risque pour les personnes concernées, les modèles de communication et les règles de clôture, d'analyse des causes et de vérification des actions correctives.

13.2 Signalement interne. Toute personne qui opère pour le Prestataire est tenue de signaler sans retard, et en tout état de cause dans l'heure, tout événement suspect, par les canaux dédiés et sans effectuer d'analyses préliminaires, avec interdiction d'altérer ou de détruire les preuves.

13.3 Confinement et conservation des preuves. La procédure prévoit des mesures typées de confinement, parmi lesquelles la révocation des sessions et des autorisations, le blocage des comptes, l'isolement du conteneur concerné, la suspension de la fonction concernée, la rotation des secrets, la révocation des liens temporaires vers les fichiers et le blocage des communications sortantes, ainsi que le gel et l'extraction des preuves avec vérification d'intégrité.

13.4 Notification au Client. Le Prestataire notifie au Client toute violation concernant ses données dans les 48 heures à compter du moment où il en a connaissance, indépendamment du niveau de risque, avec le contenu prévu par l'art. 33, paragraphe 3, du règlement, et transmet des mises à jour périodiques jusqu'à la clôture du dossier, conformément à l'art. 9 de l'Annexe A.

13.5 Registre des violations. Le Prestataire tient un registre des violations de données à caractère personnel qui documente les circonstances, les effets, les mesures adoptées, les décisions relatives aux notifications et leurs motifs, y compris les quasi-violations interceptées avant qu'elles ne produisent des effets.

13.6 Réexamen et test. La procédure est réexaminée au moins une fois par an et après chaque violation classée à risque moyen ou élevé, et elle fait l'objet d'un test de simulation une fois par an.

14. Personnel

14.1 Confidentialité. Les personnes autorisées au traitement des données des Clients ont signé des accords de confidentialité, dont l'obligation demeure après la cessation de la relation.

14.2 Autorisation et instructions. L'autorisation de traiter est attribuée aux seules personnes qui en ont besoin pour la fourniture du Service, pour l'assistance, pour la maintenance et pour la sécurité, avec des instructions écrites sur les modalités du traitement.

14.3 Accès aux données des Clients. L'accès du personnel aux données des Clients s'effectue au moyen des outils de la plateforme, est soumis aux contrôles de la section 2 et est consigné conformément à l'alinéa 2.8 et à la section 6.

14.4 Formation. Un programme de formation du personnel en matière de protection des données à caractère personnel et de sécurité de l'information est en cours d'adoption dans le cadre du système de management visé à l'alinéa 1.3. Le Prestataire ne déclare pas, à la date de la présente Annexe, de formation déjà dispensée.

15. Révision de la présente Annexe

15.1 Mise à jour. Le Prestataire peut mettre à jour la présente Annexe pour refléter l'évolution technique et organisationnelle des mesures, à condition que le niveau global de sécurité ne soit pas réduit, au sens de l'art. 12.5 des Conditions.

15.2 Versionnement. Chaque version est identifiée par un code et par une empreinte numérique SHA-256 du texte. Les versions précédentes restent accessibles au Client pendant toute la durée du Contrat.

15.3 Communication. Les mises à jour sont communiquées selon les modalités et les préavis de l'art. 13 des Conditions. Les mises à jour qui entraînent une réduction des garanties ouvrent droit à la résiliation sans pénalités conformément à l'art. 13.2 des Conditions.

15.4 Réexamen périodique. Le Prestataire réexamine les mesures selon la périodicité de l'alinéa 1.4 et met à jour la présente Annexe en cas de variation substantielle.