Algeria AgencyIntelligence artificielle
L’analyse d’impact, avant de brancher un assistant sur vos données clients
Elle se fait avant la mise en service, et c’est la seule chose qui la distingue d’un compte rendu. Après, elle décrit un risque qui s’est réalisé ou non.
Une école privée d’Alger veut brancher un assistant sur sa boîte d’inscriptions : répondre aux questions de dossier, orienter le reste vers le secrétariat. Le prototype marche. Trois semaines avant l’ouverture, quelqu’un demande si les messages contiennent des informations sur des mineurs. Ils en contiennent, et la question aurait dû être posée le premier jour.
C’est ce que fait une analyse d’impact, et sa valeur tient entièrement à sa date : conduite avant, elle peut arrêter un projet ; conduite après, elle décrit un risque qui s’est déjà réalisé ou non. Pour un projet d’intelligence artificielle, elle arrive au moment où l’architecture se décide, ce qui est aussi le moment où elle coûte le moins cher à écrire.
Cet article dit quand elle est exigée, ce qu’elle contient, et surtout ce qu’il faut faire quand son résultat est mauvais. Il ne remplace pas le cadre complet ni l’avis d’un juriste sur votre cas ; il décrit une procédure et le raisonnement qu’elle demande.
Avant, ou ce n’est pas une analyse d’impact
La différence entre une analyse d’impact et un compte rendu est une date. Le même document, la même rigueur, les mêmes pages : conduit avant la mise en service, il peut faire annuler un projet ; conduit après, il ne peut plus faire que constater.
Ce n’est pas une subtilité administrative, c’est la fonction de l’instrument. Il existe pour qu’une entreprise regarde ce qu’elle s’apprête à faire pendant qu’elle peut encore ne pas le faire, et cette fenêtre se ferme le jour de l’ouverture.
La conséquence pratique est un moment précis dans un projet, et ce n’est ni le début ni la fin : c’est quand l’architecture est arrêtée et avant que le développement commence. Plus tôt, on analyse une intention et les réponses sont vagues ; plus tard, on analyse un investissement et personne ne veut de la réponse.
Pour un traitement déjà en service, la seule réponse tenable est de la faire maintenant et de la dater d’aujourd’hui, en assumant qu’elle est tardive. Une analyse tardive et honnête est un dossier avec un point faible ; une analyse antidatée est autre chose, et c’est le seul geste de ce domaine qui ne se rattrape pas.
Ce que la loi demande, et quand
La loi 18-07 du 10 juin 2018, modifiée et complétée par la loi 25-11 du 24 juillet 2025, impose une analyse d’impact avant la mise en œuvre d’un traitement présentant un risque élevé pour les droits et libertés des personnes. Le texte la veut anticipée : c’est l’antériorité qui est exigée, pas seulement l’existence du document.
Elle s’accompagne d’une seconde règle qui surprend et qui est la plus utile à connaître : lorsque le risque résiduel demeure élevé après les mesures envisagées, l’autorité doit être consultée. L’analyse n’est donc pas un document interne dans tous les cas — elle peut déboucher sur une démarche.
C’est aussi l’une des quatre pièces qu’un contrôle demande, aux côtés du registre, des journaux et des notifications de violation. L’ordre dans lequel elles sont demandées est logique : le registre dit ce que vous faites, l’analyse dit ce que vous avez examiné avant de le faire.
Ce qui précède décrit l’état d’une réglementation au 21 août 2026 et ne remplace pas l’avis d’un avocat. Savoir si votre traitement précis relève du risque élevé est une lecture de texte appliquée à votre cas, et c’est une question de juriste — nous décrivons la procédure, pas votre situation.
Ce qui rend un traitement « à risque élevé »
Trois familles reviennent et elles se reconnaissent sans compétence juridique. Les données sensibles : santé, biométrie, opinions, données judiciaires. Les personnes vulnérables : mineurs, patients, candidats à un emploi, personnes en situation de dépendance vis-à-vis de vous. Et l’échelle : un traitement systématique, automatisé, portant sur beaucoup de monde.
Un assistant branché sur une messagerie client tombe rarement dans la première famille par conception et fréquemment par accident. Personne ne prévoit qu’un client écrira son état de santé dans un message de réclamation ; c’est pourtant ce qui arrive dans une pharmacie, une assurance ou une école.
La deuxième famille est celle que les projets d’assistant sous-estiment le plus, parce qu’elle ne dépend pas du contenu mais du rapport. Un candidat qui écrit à un employeur, un patient qui écrit à sa clinique et un parent qui écrit à l’école de son enfant ne sont pas dans la position d’un acheteur : ils ne peuvent pas simplement aller ailleurs.
La troisième est mécanique et c’est celle que l’automatisation crée à elle seule. Lire trois cents messages par un humain et les lire par un système sont deux traitements différents du point de vue du risque, même quand le contenu est identique — le second est systématique, il conserve, et il produit une trace. C’est la même bascule que celle qui fait qu’un moteur interne ne dépasse jamais la qualité du catalogue qu’on lui donne : ce qui change n’est pas l’intention, c’est l’échelle.
Le brouillon d’une heure
L’analyse complète prend du temps ; la version qui décide en prend une. Quatre questions, écrites à la main, au moment où l’architecture se discute : qu’est-ce que le système reçoit, qu’est-ce qu’il en fait, qui peut le lire, et qu’est-ce qui se passe s’il se trompe.
La quatrième est celle qui fait le tri. Un assistant qui propose un créneau de rendez-vous et se trompe fait perdre dix minutes ; un assistant qui répond à une question sur un traitement médical et se trompe fait autre chose, et la différence apparaît dans la réponse à cette seule question.
Ce brouillon n’a aucune valeur réglementaire et il a une valeur de décision énorme, parce qu’il arrive assez tôt pour changer l’architecture plutôt que pour la documenter. La plupart des projets que nous avons vus réorienter l’ont été à ce moment-là, pas au terme de l’analyse formelle.
Gardez-le. Il devient la première page de l’analyse complète, et il porte quelque chose que la version finale perd toujours un peu : ce que l’équipe croyait faire avant d’avoir écrit les détails.
Décrire le traitement sans le vendre
La première partie du document décrit ce que le système fait, et c’est là que la plupart des analyses partent de travers : elles décrivent une intention commerciale au lieu d’une opération. « Améliorer la réactivité du service client » n’est pas une description de traitement.
Ce qui en est une tient en quatre éléments : les données reçues, champ par champ ; ce qui leur est ajouté par vos systèmes avant traitement ; ce que le système en fait ; et où tout cela circule. Le deuxième point est le plus oublié — un assistant utile reçoit la fiche client et l’historique, que le client n’a pas écrits.
Cette description est presque entièrement dans votre registre si vous l’avez écrit. Les six colonnes, remplies sur un cas réel produisent exactement ces éléments, et c’est la deuxième fois dans ce cluster que le registre transforme un travail de plusieurs jours en une lecture d’une heure.
Écrivez-la au présent et au niveau du champ. Un document qui dit « les données nécessaires » ne permet à personne de juger de quoi que ce soit, et il ne permet pas non plus, six mois plus tard, de savoir si le système fait toujours ce que l’analyse décrivait.
Les risques pour les personnes, pas pour l’entreprise
C’est l’inversion qui décide de la qualité de tout le document, et c’est celle que presque personne ne fait spontanément. Une entreprise qui liste ses risques écrit : amende, atteinte à la réputation, perte d’un client, interruption de service. L’instrument demande autre chose : ce que les personnes concernées risquent, elles.
Le même incident se décrit alors différemment. Une fuite de la base d’inscriptions d’une école n’est pas « un risque d’image » : c’est la divulgation de l’adresse et des horaires d’enfants. Un assistant qui répond de travers à une question de facturation n’est pas « un risque de litige » : c’est une personne qui paie ce qu’elle ne doit pas.
Cette inversion a une conséquence que les directions découvrent en la faisant : elle produit une hiérarchie différente. Les risques les plus graves pour l’entreprise et les plus graves pour les personnes ne sont presque jamais les mêmes, et un dispositif conçu sur la première liste ne protège pas contre la seconde.
C’est aussi ce qui rend la section suivante possible. Un risque pour l’entreprise s’arbitre toujours — on l’assume, on l’assure, on le provisionne. Un risque grave pour une personne qui n’a pas choisi d’être exposée ne s’arbitre pas de la même façon, et c’est précisément ce que l’analyse est faite pour rendre visible.
Les mesures : ce qui réduit, et ce qui déplace
La troisième partie liste ce qui réduit les risques identifiés, et elle se juge à une propriété simple : une mesure qui n’est pas vérifiable n’en est pas une. « Sensibiliser les équipes » ne réduit rien de mesurable ; « le système n’a accès qu’aux commandes des trente derniers jours » est vérifiable en ouvrant une configuration.
Trois mesures font le gros du travail sur un assistant, et elles sont architecturales plutôt que procédurales. Réduire ce qui entre — n’envoyer que les champs nécessaires. Réduire ce qui est conservé — la durée chez vous et chez le fournisseur. Et réduire ce que le système a le droit de faire seul, en écrivant ce qu’il transmet.
Attention aux mesures qui déplacent au lieu de réduire. Chiffrer une base ne réduit pas le risque d’un accès légitime mal intentionné ; anonymiser les champs structurés ne fait rien pour ce que les gens écrivent en texte libre ; et faire signer une charte déplace la responsabilité sans changer ce qui sort.
Le meilleur test d’une mesure est de se demander ce qu’elle empêche exactement. Si la réponse est « cela montre notre sérieux », elle appartient au dossier commercial et pas à l’analyse — et le mode de défaillance de ces systèmes, qui est de se tromper avec assurance n’est atténué par aucune charte.
Le risque résiduel, la ligne que personne n’écrit
Après les mesures, il reste quelque chose. Cette ligne est la conclusion du document et c’est celle qui manque dans la quasi-totalité des analyses que nous lisons : elles listent des risques, listent des mesures, et s’arrêtent, laissant entendre que la soustraction donne zéro.
Elle ne donne jamais zéro, et l’écrire est ce qui rend le document utile à une direction. Un dirigeant ne peut pas décider sur une liste de risques et une liste de mesures ; il peut décider sur une phrase qui dit ce qui reste et à qui cela arriverait.
C’est aussi la ligne qui a une conséquence réglementaire directe. Lorsque le risque résiduel demeure élevé, l’autorité doit être consultée — ce qui signifie qu’une analyse honnête peut ouvrir une démarche, et qu’une analyse qui conclut systématiquement à un risque faible s’est peut-être écrite pour éviter cette conclusion.
Écrivez-la en une phrase, avec un sujet et un verbe. « Le risque résiduel porte sur les messages en texte libre, que nous ne savons pas filtrer, et concerne les personnes qui écrivent spontanément des informations de santé » est une conclusion. « Risque résiduel : modéré » n’en est pas une.
Quand le résultat doit annuler le projet
Une analyse qui ne peut pas conclure à l’arrêt n’est pas une analyse, c’est une formalité datée. Il faut donc savoir à quoi ressemble le cas où elle conclut ainsi, parce qu’il ne ressemble pas à un échec technique.
Le premier cas est celui où le risque résiduel élevé porte sur des personnes qui ne peuvent pas s’en protéger, et où aucune mesure disponible ne le réduit. Un assistant lisant des dossiers de candidats à un emploi en est un exemple courant : le candidat ne peut ni refuser ni aller ailleurs, et il ne saura jamais ce que le système a fait de sa lettre.
Le deuxième est celui où les mesures nécessaires coûtent plus que ce que le projet rapporte. C’est un arrêt heureux et il est fréquent : une entreprise qui découvre qu’un assistant conforme demande une architecture de nettoyage, une demande d’autorisation et un contrat de sous-traitance pour trente messages par jour vient d’apprendre quelque chose d’utile, et pas quelque chose de triste.
Le troisième est le plus difficile à admettre : le projet est possible, il est rentable, et personne dans l’entreprise ne peut tenir ce qu’il exige au quotidien. Une analyse peut conclure à l’arrêt pour cette raison-là, et la même question se pose déjà pour ce que vos employés utilisent sans projet — la capacité à tenir une règle est une contrainte réelle et pas un détail d’organisation.
La consultation de l’autorité
Quand le risque résiduel demeure élevé, la consultation n’est pas une punition : c’est le mécanisme prévu pour un cas que le texte anticipe. L’entreprise expose ce qu’elle veut faire, ce qu’elle a examiné et ce qui reste, et elle reçoit une position avant d’ouvrir plutôt qu’après.
La différence avec un contrôle mérite d’être dite clairement, parce que la confusion est fréquente et coûteuse : un contrôle constate ce que vous avez fait, une consultation porte sur ce que vous envisagez. Arriver de soi-même avec un dossier construit n’est pas la même position que d’être instruit après coup.
Le dossier est celui que vous venez d’écrire, et c’est le seul intérêt pratique de bien le faire dès le départ : une analyse rédigée sérieusement se transmet telle quelle, une analyse écrite pour la forme demande d’être refaite au moment où le temps manque.
Nous ne décrirons pas le déroulé d’une telle démarche ni son délai, parce que nous n’avons pas d’observation assez large pour le faire honnêtement et que les modalités relèvent de textes d’application. Ce que nous pouvons dire est que la voie existe et qu’elle est écrite.
Le test du paragraphe unique
Voici le contrôle, et il se fait cette semaine, sans nous et sans document. Écrivez en un paragraphe ce que votre assistant fera, tel que vous l’écririez à un client qui le demande — pas à un comité, pas à un fournisseur : à la personne dont les messages seront traités.
Puis lisez-le et posez deux questions. Est-ce que cette personne, en lisant ce paragraphe, apprendrait quelque chose qu’elle ne soupçonnait pas ? Et est-ce qu’il y a une phrase que vous avez hésité à écrire ?
Les deux réponses sont des indicateurs de risque plus fiables qu’une grille. Ce qu’un client n’aurait pas soupçonné est exactement ce que l’analyse doit examiner ; et la phrase que vous avez hésité à écrire est, dans notre expérience, celle qui figurera dans le risque résiduel.
Cet exercice prend un quart d’heure et il précède utilement tout le reste. Une entreprise qui ne peut pas écrire ce paragraphe honnêtement n’a pas un problème de conformité : elle a un projet dont elle ne peut pas décrire l’objet à la personne qu’il concerne.
Ce que nous faisons, et ce que nous refusons
Nous conduisons l’analyse au moment où l’architecture se décide, pas après le prototype, et nous écrivons la description au niveau du champ — ce qui entre, ce que vos systèmes ajoutent, ce qui circule et où. C’est la partie technique, elle est longue, et elle est celle que personne d’autre ne peut produire à votre place.
Nous portons aussi l’inversion : la liste des risques est écrite du point de vue des personnes concernées, et nous la relisons avec vos équipes plutôt qu’avec votre direction, parce que ce sont elles qui savent ce que les clients écrivent réellement.
Nous n’écrivons pas de risque résiduel faible pour faire passer un dossier. C’est la demande implicite la plus fréquente sur ce sujet, elle ne se formule jamais ainsi, et y céder détruit exactement ce qui rend le document utile — un document dont la conclusion était connue d’avance n’a examiné rien.
Et nous ne portons pas d’appréciation sur le caractère « à risque élevé » de votre traitement. C’est une qualification juridique appliquée à votre cas ; elle appartient à un avocat ou à votre délégué, et nous nous arrêtons à la description de ce que le système fait — qui est, dans la pratique, ce dont ils ont besoin pour trancher.
Questions fréquentes
Faut-il une analyse d’impact pour un simple assistant de réponse ?
Cela dépend de ce qu’il reçoit et de qui écrit, pas de sa complexité technique. Un assistant qui traite des demandes de livraison et un assistant qui traite des dossiers de candidature sont deux traitements très différents du point de vue du risque pour les personnes. La qualification appartient à un juriste ; le brouillon d’une heure vous dira en revanche tout de suite dans quelle direction vous allez.
Notre traitement est déjà en service. Est-il trop tard ?
Trop tard pour qu’elle joue son rôle d’anticipation, pas trop tard pour la faire. Conduisez-la maintenant, datez-la d’aujourd’hui et assumez qu’elle est tardive : c’est un dossier honnête avec un point faible. La seule chose à ne jamais faire est de l’antidater, ce qui transforme une non-conformité administrative en autre chose.
Qui doit la rédiger ?
La description technique vient de ceux qui construisent le système, l’évaluation des risques se fait avec les équipes qui reçoivent réellement les messages, et l’arbitrage final appartient à la direction. Le délégué à la protection des données, quand il existe, en est le point de rassemblement. Une analyse écrite par une seule de ces trois parties se reconnaît immédiatement.
Combien de pages doit-elle faire ?
Assez pour que quelqu’un d’extérieur comprenne ce que le système reçoit et ce qui reste comme risque, ce qui tient rarement en moins de trois pages et rarement en plus de dix pour un projet de cette taille. La longueur n’est pas un critère de qualité ; l’absence de la ligne de risque résiduel en est un, et elle manque dans presque tous les documents que nous lisons.
Que se passe-t-il si l’analyse conclut à un risque élevé ?
Deux voies : réduire le risque en changeant l’architecture — ce qui est le cas le plus fréquent et le plus utile — ou, si le risque résiduel demeure élevé, consulter l’autorité avant la mise en service. Une troisième voie existe et elle est légitime : ne pas faire le projet, ce qui est le sujet de la section 8.
Peut-on réutiliser l’analyse d’un autre projet ?
La structure, oui, et cela fait gagner du temps. Le contenu, non : les risques dépendent de ce que vos clients écrivent, de qui ils sont et de ce que votre système ajoute au message, et ces trois éléments ne se transposent pas d’une entreprise à l’autre. Une analyse recopiée décrit un traitement imaginaire, ce qui est le seul défaut vraiment grave qu’elle puisse avoir.
Où nous intervenons
Le paragraphe destiné au client a produit deux choses : ce qu’il n’aurait pas soupçonné, et la phrase que vous avez hésité à écrire. La seconde finira dans le risque résiduel.
- L’examen se mène tant que la hiérarchie technique peut encore changer, jamais après le prototype.
- Chaque champ reçu est nommé, avec ce que vos propres systèmes lui ajoutent avant l’envoi.
- Ceux qui ouvrent les messages tous les jours relisent les risques, plutôt qu’une salle de réunion.
Nous ne rédigerons pas une conclusion rassurante pour débloquer une mise en service, et nous ne qualifions pas juridiquement votre traitement.
À lire ensuite
Entraîner un modèle : les trois cas où ça vaut la peine
Un entraînement change la forme des réponses, presque jamais leur contenu. Voici ce qu’il faut vraiment fournir, et les trois situations où il est le bon outil.Intelligence artificielle : ce qu’elle fait bien, ce qu’elle invente, et ce que vous ne pouvez pas lui confier
Son mode de défaillance n’est pas la panne, c’est l’erreur confiante. Elle produit un texte juste assez bon pour que personne ne le vérifie.L’IA que vos employés utilisent déjà : ce qui sort de l’entreprise, et la page de règles qui suffit
Vous n’avez rien acheté et elle est déjà en service, sur des comptes personnels. Le problème n’est pas l’outil, c’est que personne ne sait ce qui y passe.
Parlons de votre projet
Un audit gratuit, sans engagement : nous regardons votre présence en ligne et nous vous disons ce qui coince.