Réexaminer une AIPD après un changement de produit

Une évolution de produit impose de réexaminer son AIPD au moins lorsqu’elle modifie le risque présenté par les opérations de traitement. Il ne faut ni refaire automatiquement toute l’analyse à chaque version, ni réutiliser sa conclusion parce que le nom du logiciel reste identique. Comparez le traitement analysé et celui qui sera réellement utilisé, puis actualisez les hypothèses, mesures et décisions affectées. Source : RGPD, Art. 35(11).

L’objectif est de décider si l’évolution peut être mise en service, avec quelles limites et sur quelles preuves. Un changement de date sur le document ne répond pas à cette question. Le guide général de l’AIPD traite la réalisation initiale ; ici, le point de départ est une analyse existante et une modification déterminée.

Retrouver le traitement réellement évalué

Identifiez la version de référence, sa date et les conditions de sa conclusion. Une phrase comme « risque acceptable sous réserve d’habilitations limitées » n’établit pas que ces habilitations ont été déployées. Reprenez les réserves ouvertes, les mesures effectivement réalisées et les éventuels écarts déjà connus.

Décrivez ensuite l’évolution en termes d’opérations : qui pourra consulter, calculer, exporter ou transmettre quelles données, pour quelle finalité et à partir de quand ? La description commerciale « nouveau tableau de bord » est insuffisante si elle couvre aussi un rapprochement entre agences ou un téléchargement nominatif.

L’Art. 35(7) fournit quatre points d’appui : description et finalités, nécessité et proportionnalité, risques pour les personnes, mesures envisagées. C’est l’ensemble résultant de la modification qui doit rester intelligible, même si seules certaines parties du document changent. Source : Art. 35(7)(a) à (d).

Conservez une trace des composants inchangés avec la raison de leur maintien. « Hébergement confirmé identique par le fournisseur, schéma de version joint » est une conclusion examinable. « Aucun impact RGPD » ne permet pas de savoir si quelqu’un a regardé les nouveaux accès.

Choisir l’étendue de la revue

Une revue ciblée convient lorsque le changement et ses conséquences peuvent être isolés. Elle peut prendre la forme d’une annexe liée à une version précise, si l’AIPD et l’annexe décrivent clairement le traitement final et ses garanties. Le RGPD ne prescrit pas un format unique de document.

Une révision plus large devient nécessaire lorsque les hypothèses structurantes changent : nouveau public, extension massive du périmètre, nouvelle finalité, décisions individuelles supplémentaires ou architecture remplaçant les contrôles précédents. Dans ce cas, empiler des annexes contradictoires peut rendre l’analyse inutilisable.

Une évolution apparemment protectrice mérite aussi un examen. Remplacer les identifiants visibles par des codes réduit certaines expositions, mais crée éventuellement une table de correspondance et de nouveaux accès administratifs. Il faut examiner l’effet global, puis expliquer pourquoi le risque baisse, reste identique ou se déplace.

Lorsque aucune AIPD n’existait, vérifiez d’abord si le traitement modifié en nécessite désormais une selon l’Art. 35(1), les cas du paragraphe 3 et les listes applicables. Une fiche de changement ne remplace pas une AIPD obligatoire. À l’inverse, le nom « intelligence artificielle » ou « export » ne dispense pas d’analyser le traitement concret. Source : Art. 35(1), (3), (4) et (5).

Exemple : deux évolutions du même portail

Dossier entièrement fictif. L’organisme Horizon utilise un portail de suivi de dossiers individuels. Une AIPD A-4 a déjà été réalisée pour cet usage. Elle décrit des agents affectés à un secteur, une consultation dossier par dossier et l’absence d’export global accessible au profil courant. Sa conclusion dépend notamment de cette séparation des accès.

Le projet V-5 comporte deux changements. Le premier améliore le contraste des boutons sans modifier les informations, destinataires ou opérations. Le second permet aux responsables de secteur de télécharger l’historique de tous les dossiers du secteur. Les finalités déclarées restent la gestion et le suivi des dossiers.

Pour le contraste, l’équipe vérifie la description fonctionnelle et confirme l’absence de collecte ou de bibliothèque externe nouvelle. Elle conserve une note courte : les hypothèses pertinentes de l’AIPD ne changent pas. Si une nouvelle bibliothèque transmettait des événements de navigation, la conclusion devrait être revue ; ce n’est pas le cas posé dans l’exemple.

Pour l’export, le changement est substantiel au regard du risque : des informations auparavant consultées séparément deviennent une copie facilement transportable et conservable hors du portail. La finalité annoncée identique ne neutralise pas cette différence. Horizon ouvre donc une revue ciblée A-4/R-1 avant d’activer cette fonction.

Annexe de revue A-4/R-1 renseignée

Le tableau comporte des réponses, mais ne prétend pas être l’AIPD complète. Il renvoie aux sections inchangées de A-4 et décrit précisément celles à modifier. Si les dossiers comportent des informations particulièrement sensibles, leur nature et leurs conséquences doivent apparaître dans l’évaluation ; le seul mot « confidentiel » ne suffit pas.

Évaluer le risque pour les personnes

Décrivez un événement et ses conséquences, pas seulement une faiblesse technique. Dans A-4/R-1, une copie envoyée au mauvais interlocuteur pourrait révéler les démarches et difficultés d’une personne. Une copie périmée pourrait aussi orienter une action sur la base d’un état devenu inexact. La perte d’image d’Horizon n’est pas le critère central.

Appréciez la gravité et la vraisemblance en exposant leurs raisons. Le nombre de dossiers exportables, la sensibilité des situations, les destinataires et la facilité de retransmission comptent. Une note « faible » sans justification n’explique pas pourquoi une nouvelle copie générale serait acceptable. La CNIL rappelle que la gravité s’évalue pour les personnes concernées. Source : CNIL, risque sur la vie privée.

Évaluez les mesures pour l’événement qu’elles traitent. Un journal d’export aide à retrouver l’origine d’une copie ; il ne bloque pas son envoi à un tiers. Une limitation au secteur réduit le périmètre exposé ; elle ne supprime pas le besoin de sécuriser la copie. Additionner des dispositifs ne démontre pas leur efficacité.

Les droits doivent suivre les données. La propagation des rectifications est utile ici : une correction dans le portail doit conduire à remplacer ou retirer les exports encore utilisés selon leur finalité. Une archive historique exacte ne reçoit pas automatiquement le même traitement qu’un tableau servant à préparer la prochaine réunion.

Vérifier les mesures avant de conclure

Horizon prépare une vérification avec des dossiers fictifs répartis entre deux secteurs. Le responsable du secteur A doit obtenir uniquement son périmètre ; un profil non habilité ne doit pas pouvoir déclencher la même génération par un autre accès. Le fichier obtenu doit contenir les colonnes retenues, sans feuille intermédiaire ni commentaires supplémentaires.

La vérification porte aussi sur le cycle d’utilisation. Dans cet exemple, le responsable conserve l’export dans l’espace réservé jusqu’à la réunion, puis le supprime au plus tard deux jours ouvrés après. Ce délai est un choix illustratif justifié par ce besoin ponctuel, pas une durée légale. Si un suivi doit continuer, il reprend dans le portail de référence.

L’équipe conserve la version vérifiée, les profils utilisés, les résultats et les limites du contrôle. Ces vérifications sont un programme proposé pour ce cas fictif, pas des essais réalisés sur un produit. Une capture de l’écran de paramétrage prouve le paramétrage affiché ; elle ne démontre pas nécessairement le comportement de tous les accès.

Si le filtrage du secteur n’est pas assuré, l’export reste inactif. Si un usage sans copie répond au besoin, il peut être retenu à sa place. Le dossier conserve alors l’abandon de la fonction et la raison de ce choix, sans prétendre que l’export a été sécurisé. Les exigences de sécurité et de protection par défaut restent applicables indépendamment de la présentation de l’AIPD. Sources : Art. 25(2) et 32(1).

Décider sans transformer l’avis du DPO en autorisation

Lorsque le DPO est désigné, le responsable lui demande conseil pour l’AIPD. Le prestataire fournit l’assistance et les informations prévues par son rôle. Les équipes métier et techniques doivent pouvoir expliquer les besoins et les mesures ; le responsable de traitement reste chargé de la décision. Sources : Art. 35(2), 28(3)(f) et 24(1).

Dans A-4/R-1, la fiche de décision finale doit identifier la variante retenue, les vérifications concluantes, les éventuelles limites restantes et l’analyse du risque résiduel. Tant que ces éléments ne sont pas disponibles, la conclusion reste « non activé, revue en cours ». Une date de lancement prévue ne constitue pas une preuve de conformité.

Si un risque résiduel élevé subsiste malgré les mesures envisagées, la consultation préalable de la CNIL doit être examinée et effectuée lorsque les conditions de l’Art. 36(1) sont réunies. La CNIL précise que la persistance d’un tel risque impose sa consultation. Une acceptation interne du risque ne remplace pas cette démarche. Sources : Art. 36(1) et CNIL, transmission de l’AIPD.

En cas de désaccord entre DPO et direction, conservez les arguments et la décision réelle. N’inscrivez pas « validé par le DPO » lorsqu’il a formulé une réserve.

Garder une analyse utilisable après le déploiement

Rattachez la décision à la version effectivement mise en service. Une configuration différente de celle examinée demande une nouvelle appréciation. Vérifiez également les retours d’usage : les équipes peuvent créer des contournements, partager les copies ailleurs ou demander de nouvelles colonnes.

Planifiez un suivi proportionné, sans attendre automatiquement une échéance annuelle. L’Art. 35(11) pose un examen si nécessaire et au moins lors d’une modification du risque. Une revue programmée complète ce déclencheur ; elle ne permet pas d’ignorer un changement découvert entre deux réunions. Source : Art. 35(11).

Ce qu’il faut retenir

• Comparez les opérations et hypothèses, pas seulement les versions du logiciel.
• Reliez chaque mesure au risque qu’elle réduit et à sa preuve d’efficacité.
• Une annexe ciblée convient si elle décrit clairement le traitement résultant.
• Distinguez conception, vérification et décision effective de mise en service.

FAQ

Une baisse du risque doit-elle être documentée ?

Oui, lorsqu’elle modifie l’analyse pertinente. Expliquez la mesure et ses effets, notamment les risques déplacés vers un autre composant. L’amélioration annoncée ne prouve pas à elle seule l’amélioration réelle.

L’AIPD du fournisseur suffit-elle ?

Elle peut fournir des informations, mais ne décrit pas nécessairement votre finalité, vos utilisateurs, vos données et votre paramétrage. Il faut rattacher ses conclusions au traitement dont vous êtes responsable.

Faut-il transmettre chaque nouvelle version à la CNIL ?

Non. L’actualisation ne crée pas une obligation générale de dépôt. Examinez les cas de consultation préalable et les éventuelles dispositions particulières applicables, plutôt que d’assimiler toute revue à une demande d’autorisation.

Recevez nos analyses pratiques sur la conformité RGPD dans la newsletter.

À propos de l’auteur. Thiébaut Devergranne est docteur en droit privé, titulaire du CAPA et fondateur de Legiscope. Il travaille depuis plus de vingt ans sur le droit des technologies et la protection des données.