Comment les équipes métier peuvent déployer des applications créées avec l’IA sans exposer les données clients

Lorsque RedAccess a recherché des applications créées avec des outils de programmation par IA et publiées sur les domaines de ces outils, l’entreprise en a trouvé plus de 5 000 pratiquement dépourvues de sécurité ou d’authentification. Parmi les captures d’écran partagées avec Wired figurait l’historique complet des échanges du chatbot d’un commerçant avec ses clients, avec leurs noms complets et coordonnées. Wired n’a pas pu confirmer l’authenticité des données examinées. Les applications restaient néanmoins accessibles.

Les données clients d’une application créée avec l’IA peuvent fuiter bien au-delà de l’écran conçu dès que l’outil est connecté à Salesforce, HubSpot, Pipedrive ou Zoho. Un outil de suivi du pipeline n’affiche qu’un tableau de bord de comptes, mais sa clé peut ouvrir bien davantage. Avant de transmettre le lien à votre équipe, vérifiez donc ce que cette clé permet d’atteindre.

En bref

• L’identifiant CRM détermine l’ampleur d’une fuite. Donnez à l’outil son propre identifiant CRM aux droits restreints, utilisez un utilisateur dédié avec peu de privilèges lorsque le CRM rattache l’accès à un utilisateur, conservez l’identifiant dans les paramètres d’environnement du serveur ou un coffre de secrets, et réservez son utilisation au code côté serveur.
• Chaque erreur de déploiement exposant des fiches clients, le pipeline ou les tarifs a une correction applicable à l’aide d’une consigne à copier-coller. Votre outil de programmation par IA effectue le changement, puis vous réalisez vous-même un test court pour vérifier son efficacité.
• L’hébergement de l’outil dépend de ses actions sur le CRM. Les outils en lecture seule peuvent fonctionner sur un serveur contrôlé par l’équipe, accessible sur un réseau privé ou après connexion avec le compte de l’entreprise. Ceux qui écrivent dans le CRM passent d’abord par l’informatique ou l’administrateur CRM.
• Lorsque le RGPD et le CCPA s’appliquent, ils couvrent la copie des données clients conservée par l’outil et chaque service auquel il les transmet. La plupart des outils de vente et d’assistance ne sont pas à haut risque au sens du règlement européen sur l’IA. Les principales exceptions concernant les clients sont les décisions de crédit visant des particuliers, l’évaluation des risques ou la tarification de leur assurance vie ou maladie, et l’IA qui déduit leurs émotions de leur visage ou de leur voix.

Ce qu’une clé CRM divulguée permet d’atteindre

Une clé d’API CRM exposée donne accès à ce que son utilisateur ou son application peut atteindre, et non uniquement à ce qu’affiche votre tableau de bord. Dans Salesforce et Pipedrive, une clé provenant d’un compte administrateur peut lire, et généralement modifier, tous les contacts, comptes et affaires accessibles à cet administrateur. Les clés HubSpot et Zoho portent les autorisations qui leur ont été accordées, et une autorisation de groupe Zoho couvre tout ce que son utilisateur peut faire.

Voici comment chacun des quatre CRM définit cet accès et comment le réduire. Dans les colonnes ci-dessous, une portée d’autorisation, ou scope, désigne la liste des actions permises à un identifiant.

Chaque ligne reprend les termes du fournisseur. La référence des portées Salesforce précise que full « englobe toutes les autres portées ». HubSpot considère désormais les applications privées comme héritées et recommande les Service Keys pour les nouvelles intégrations entre systèmes ; les applications privées héritées existantes utilisent toujours l’ancienne référence des portées, notamment celles relatives aux données sensibles des comptes Enterprise.

La formulation de Pipedrive vient de sa documentation sur l’authentification. La documentation des portées Zoho indique qu’une portée de groupe donne un « accès complet à toutes les fonctions que l’utilisateur peut exécuter sur l’enregistrement ». Son propre exemple de requête demande ZohoCRM.modules.ALL.

Le principe est commun aux quatre. Un identifiant porte les droits d’un utilisateur ou les portées qui lui ont été accordées : attribuez donc à l’outil son propre identifiant d’intégration et réduisez cet accès autant que le CRM le permet. Lorsque l’accès dépend d’un utilisateur, utilisez un compte dédié à faibles privilèges plutôt que le compte administrateur d’une personne.

N’accordez l’écriture que si l’outil doit écrire, ce qui le place sous la responsabilité de l’informatique. N’utilisez jamais votre propre compte administrateur ni votre jeton personnel.

Rattacher un identifiant hérité à une personne peut aussi casser l’intégration à son départ. La présentation des applications privées héritées de HubSpot indique que, si l’utilisateur ayant créé une application privée héritée est supprimé, certains appels d’API utilisant son jeton échouent. Les Service Keys HubSpot évitent ce problème : ce sont des identifiants au niveau du compte, indépendants d’un salarié. Pipedrive autorise un seul jeton d’API actif par utilisateur ; le modifier arrête toutes les intégrations qui l’utilisent.

Un identifiant étendu qui ouvre les contacts ouvre généralement aussi les affaires et les prévisions, ainsi que les devis et catalogues de prix dans la liste des modules Zoho. Les tarifs et structures de remise deviennent alors accessibles à toute personne qui le détient.

Créez l’identifiant d’intégration et réduisez ses permissions ou ses portées dans les écrans d’administration du CRM, ou demandez à l’administrateur CRM de le faire.

Les erreurs de déploiement qui exposent les fiches clients, et comment les corriger

Sept choix par défaut exposent les données clients d’un outil de vente créé avec l’IA : une clé CRM dans le code ou le navigateur, un lien public, tous les commerciaux voyant tous les comptes, des champs inutiles, des enregistrements envoyés à des services externes, aucune trace des exports et une copie qui survit à une demande de suppression. Chacun facilite une démonstration.

L’outil de programmation par IA ayant créé l’application peut appliquer la plupart de ces corrections sur demande. Adaptez chaque consigne ci-dessous à votre CRM, vos objets et vos rôles.

Le compte rendu de l’IA affirmant avoir effectué un changement ne prouve rien. Le test sous chaque consigne constitue votre preuve. Appliquez les consignes au code, sans jamais coller de clés actives ni de vraies fiches clients dans la conversation.

Retirez la clé CRM du code, du navigateur et de la conversation

Une clé collée dans le code ou la conversation est exposée. C’est aussi le cas d’une clé stockée dans une variable d’environnement (une valeur transmise à l’application par le serveur au démarrage, que le code nomme sans la contenir) si le code qui l’utilise s’exécute dans le navigateur. Une clé lisible par le navigateur est copiable par toute personne ouvrant la page.

La documentation de Vite indique que les variables préfixées par VITE_ « seront exposées dans le code source côté client ». La documentation des variables d’environnement de Next.js explique que le préfixe NEXT_PUBLIC_ intègre lui aussi la variable aux fichiers téléchargés par le navigateur.

Une clé écrite dans un fichier commité reste dans l’historique, tout comme les secrets inscrits en dur dans les fichiers Compose survivent au conteneur. Un dépôt privé n’est pas un refuge. Le rapport 2026 de GitGuardian sur les secrets estime les dépôts internes environ six fois plus susceptibles que les dépôts publics de contenir des secrets en dur. Il relève aussi qu’environ 28 % des incidents naissent entièrement hors des dépôts, dans des outils comme Slack, Jira et Confluence.

Trouvez dans ce projet toutes les clés d’API, tous les jetons, mots de passe ou chaînes de connexion pour Salesforce, HubSpot, Pipedrive, Zoho ou tout autre CRM ou outil commercial. Vérifiez le code, chaque fichier .env et l’historique des commits du projet.

Pour chacun, indiquez :

- le fichier et la ligne où il apparaît

- s’il est inscrit directement dans le code ou lu depuis une variable d’environnement

- si le code qui l’utilise s’exécute sur le serveur ou dans le navigateur (signalez toute variable dont le nom commence par VITE_ ou NEXT_PUBLIC_)

N’affichez pas les valeurs complètes des clés. Montrez uniquement les quatre premiers caractères de chacune.

Déplacez ensuite chaque appel au CRM dans du code côté serveur qui lit la clé depuis une variable d’environnement réservée au serveur. Retirez toutes les clés du code, assurez-vous que les fichiers contenant les vraies valeurs sont exclus du dépôt et décrivez exactement les modifications. Si un point reste incertain, dites-le au lieu de deviner.

Remarque : Supprimer le message ou le commit ne rend pas une clé à nouveau secrète. Une fois collée ou commitée, la seule correction consiste à la désactiver dans le CRM.

La rotation de la clé (en créer une nouvelle et désactiver l’ancienne) est une intervention humaine. Créez l’identifiant d’intégration restreint de l’outil dans le CRM et demandez à l’informatique de vous aider à le placer dans les paramètres d’environnement du serveur. Désactivez ensuite l’ancienne clé.

Pour un jeton d’application privée compromis, HubSpot propose Rotate and expire now. Dans Pipedrive, vérifiez quelles autres intégrations utilisent l’ancien jeton avant de le modifier.

Les copies humaines des mots de passe administrateur du CRM doivent aller dans un gestionnaire de mots de passe tel que Vaultwarden, un serveur compatible avec Bitwarden. Il sert aux personnes qui se connectent. Pour la rotation centralisée des secrets utilisés par vos applications, examinez HashiCorp Vault.

Test : Ouvrez l’outil en fonctionnement dans un navigateur, ouvrez les outils de développement et recherchez dans tous les fichiers chargés (Ctrl+Maj+F, ou Cmd+Option+F sur Mac) les huit premiers caractères de la nouvelle clé. Aucune correspondance ne doit apparaître. Déclenchez ensuite une action utilisant le CRM et examinez l’onglet Réseau du navigateur. L’identifiant CRM ne doit figurer ni dans les URL, ni dans les en-têtes, ni dans le corps des requêtes. Demandez enfin à l’administrateur CRM de confirmer le rejet de l’ancienne clé ou vérifiez son statut dans les paramètres d’intégration du CRM.

Retirez l’outil du lien public

Lorsque l’outil d’IA héberge l’application, sa publication la place sur le domaine du fournisseur. RedAccess a trouvé ses applications à l’aide de simples recherches Google et Bing sur ces domaines. Une page de tarifs ou un calculateur de remises accessible ainsi est aussi lisible par un concurrent que par un commercial.

La déclaration de Lovable à Wired renvoie le réglage au créateur, avec raison. La plateforme « donne aux créateurs les outils nécessaires pour construire en sécurité, mais la configuration d’une application relève en définitive de son créateur ». C’est à vous de modifier le paramètre de publication.

Répertoriez chaque page, route d’API, téléchargement de fichier et export de cette application. Pour chacun, dites-moi :

- s’il est accessible sans connexion

- s’il renvoie des données clients, des données d’affaires ou des tarifs

Signalez chaque route qui renvoie des données à une requête non authentifiée. Ne changez encore rien ; je veux d’abord la liste.

Test : Sur un téléphone utilisant les données mobiles, hors de tout réseau privé, ouvrez l’adresse de l’outil dans une fenêtre de navigation privée. Il doit soit être inaccessible, soit s’arrêter à la connexion d’entreprise. Essayez de la même manière chaque route de la liste qui renvoie des données clients, des affaires ou des tarifs : aucune donnée ne doit sortir.

Limitez chaque commercial à ses propres comptes

Un outil sans rôles montre à chaque utilisateur l’intégralité du pipeline, des montants d’affaires et des remises. Il permet aussi à quiconque d’exporter tout le portefeuille clients avant son départ. La correction passe par des rôles vérifiés sur le serveur et liés au propriétaire CRM de chaque fiche, avec la même règle pour la recherche et l’export.

Ajoutez un contrôle d’accès à trois rôles, vérifiés côté serveur à chaque requête. Masquer des boutons, menus ou colonnes ne constitue pas un contrôle.

- Administrateur (propriétaire de l’outil et opérations commerciales) : tous les enregistrements.

- Responsable : enregistrements appartenant aux membres de son équipe.

- Commercial ou responsable de compte : uniquement les enregistrements dont il est propriétaire dans le champ propriétaire du CRM.

Tirez l’identité et le rôle de chaque utilisateur de son compte authentifié, jamais de ce qu’il peut saisir ou modifier sur la page. Appliquez la même règle aux résultats de recherche, listes, exports et réponses d’API. Refusez tout autre accès avec une réponse « accès refusé » (403).

Une fois terminé, indiquez quel contrôle de rôle couvre chaque page et route, et signalez les incertitudes.

Remarque : Masquer un menu ou une colonne n’est pas un contrôle d’autorisation. Si le serveur ne vérifie rien, une seule requête suffit toujours pour obtenir les données.

Adaptez les noms des rôles et la définition des équipes. Certaines équipes permettent aux responsables de voir toutes les régions pendant les réunions de prévision.

Test : Créez un compte commercial de test. Avec ce compte, cherchez un client dont vous savez qu’il appartient à un autre territoire : aucun résultat ne doit apparaître. Exportez la liste des comptes et vérifiez qu’elle ne contient que ceux du commercial de test. Répétez la recherche avec un responsable de test pour un compte extérieur à son équipe.

Récupérez uniquement les champs clients nécessaires à l’outil

Un outil de suivi des renouvellements a besoin des dates, des propriétaires et des noms de comptes. Un outil créé en demandant « toutes les données des comptes » récupère aussi l’historique d’achat, le statut des paiements et le texte des tickets d’assistance. Moins de champs signifie moins de données à exposer, moins d’endroits à couvrir lors d’une suppression et moins d’informations à transmettre aux services externes.

Répertoriez tous les champs de la base, du code, des écrans, des exports et des appels d’API pouvant contenir des données personnelles clients ou commerciales : noms, e-mails, téléphones, adresses, entreprise, poste, historique d’achat, valeur du compte, statut des paiements, montants d’affaires, remises, scores de prospects ou de santé client, contenu des tickets et tout identifiant unique.

Pour chaque champ, indiquez l’écran ou la fonction qui l’utilise et si l’objectif principal de l’outil en a besoin. Signalez les incertitudes plutôt que de deviner.

Modifiez ensuite l’application pour que ses requêtes CRM demandent uniquement ces champs : [les champs que vous approuvez]. Supprimez tous les autres de la copie stockée, des écrans et des exports, puis décrivez exactement les modifications.

Les permissions ou portées de l’identifiant d’intégration constituent un second verrou. Une donnée illisible par cet identifiant ne peut pas fuiter à cause d’un bug du code écrit par l’IA. Le chiffrement des données stockées relève de l’informatique : un assistant qui lit le code ne peut pas le vérifier de manière fiable.

Test : Exportez les données de l’outil en tant qu’administrateur et comparez les colonnes à votre liste de champs approuvés. Rien de plus ne doit apparaître. Ouvrez chaque écran et vérifiez que les champs supprimés ont disparu. Conservez la liste approuvée : le test suivant s’y réfère.

Vérifiez quelles données clients quittent l’outil

Un calculateur d’attrition qui envoie des notes de compte à une API d’IA, transmet des champs à un script d’analyse ou déclenche un webhook vers un autre outil copie les fiches clients hors de l’outil. Lorsque le RGPD s’applique, un service externe traitant ces données pour le compte de l’entreprise est un sous-traitant et doit être encadré par un contrat, comme expliqué plus bas.

Auditez tous les appels externes de cette application : vers OpenAI, Anthropic ou toute autre API d’IA, le CRM, les outils d’e-mail, de discussion ou d’analyse, et tout webhook.

Pour chaque appel, répertoriez précisément les champs clients ou commerciaux envoyés dans le corps de la requête ou dans l’adresse. Signalez les services susceptibles de stocker ou journaliser les données reçues, ou de les utiliser pour l’entraînement. Dites ensuite quels appels pourraient fonctionner avec moins de champs ou sans données clients.

Test : Dans chaque service recevant encore des données de l’outil, ouvrez l’écran qui liste les champs ou propriétés reçus, par exemple les propriétés utilisateur d’un outil d’analyse ou le mappage des champs d’un webhook. Comparez cette liste aux champs approuvés. Tout champ extérieur à cette liste quitte encore l’outil. Si un service ne fournit aucune liste, soumettez son nom et ses conditions de traitement au DPO ou au responsable de la confidentialité.

Journalisez chaque export et téléchargement en masse

Le bouton d’export fait sortir une liste clients ou un catalogue de prix en un clic. Sans journal, personne ne peut dire qui a pris quoi. Journaliser chaque consultation du tableau de bord noie ce signal. Enregistrez les exports, consultations en masse et suppressions.

Ajoutez un journal enregistrant chaque export, téléchargement de fichier, consultation renvoyant plus de [un nombre que vous choisissez] enregistrements et suppression. Pour chaque événement, consignez l’utilisateur, l’action, les enregistrements ou le segment concernés, le nombre de lignes et l’heure.

Configurez-le pour que le compte de base de données de l’application puisse ajouter des lignes au journal, mais pas les modifier ni les supprimer. Seuls les administrateurs peuvent le lire. Indiquez les permissions de base de données utilisées pour l’imposer et signalez tout ce qui n’a pas pu être imposé à ce niveau.

L’impossibilité de modifier doit venir des permissions du compte de base de données (celui utilisé par l’application pour communiquer avec sa base, et qui peut être limité comme tout autre compte), pas du bon comportement de l’application. Le journal est lui-même une donnée personnelle puisqu’il montre qui a pris les fiches de qui ; sa lecture reste donc réservée aux administrateurs.

Test : Exportez une petite liste avec un commercial de test, puis ouvrez le journal en administrateur et trouvez l’entrée avec le bon nombre de lignes. Demandez à l’informatique, ou à l’outil d’IA en exigeant de voir la sortie, d’essayer de supprimer cette ligne avec le compte de base de données de l’application. Une erreur de permission doit apparaître.

Alignez la copie de l’outil sur le CRM lorsqu’un client demande la suppression

Si le CRM est votre système de référence, traitez-y d’abord la suppression. Un outil conservant sa propre copie des fiches clients (cache, exports sur disque, scores calculés par client) constitue un deuxième lieu de stockage que la suppression dans le CRM n’atteint pas.

La solution évidente, un bouton supprimant en un appel tout ce qui concerne un client, comporte son propre risque si tout utilisateur peut l’actionner. À mon avis, mieux vaut conserver la plus petite copie possible pour limiter ce qu’une suppression doit retrouver.

Modifiez cette application pour qu’elle lise les fiches clients dans le CRM au besoin et stocke uniquement [les champs de votre liste approuvée que l’outil doit conserver].

Listez tous les endroits où l’application conserve encore des données clients : tables, caches, fichiers exportés, scores dérivés et journaux.

Ajoutez ensuite un outil de suppression réservé aux administrateurs. À partir d’un identifiant de fiche CRM, il montre tous les endroits où les données de ce client existent dans l’application. Après confirmation d’un administrateur, il supprime les données à tous ces endroits, scores dérivés et exports stockés compris. Il enregistre uniquement l’identifiant de la fiche, l’heure, l’auteur de la confirmation et les emplacements vidés. Tout non-administrateur qui l’ouvre reçoit « accès refusé ».

Le DPO ou le responsable de la confidentialité décide des exceptions, c’est-à-dire des données que l’entreprise doit conserver ; la consigne les laisse donc de côté.

Test : Créez un contact de test dans le CRM et laissez l’outil le récupérer, avec un score ou un export s’il en produit. Supprimez le contact dans le CRM, lancez l’outil de suppression en administrateur et vérifiez sa disparition de chaque emplacement listé. Ouvrez ensuite cet outil avec un commercial de test : « accès refusé » doit apparaître.

Où héberger un outil connecté au CRM

L’hébergement dépend de ce que l’outil fait dans le CRM. Un outil en lecture seule peut fonctionner sur un serveur contrôlé par l’équipe, accessible uniquement par un réseau privé ou après connexion avec le compte d’entreprise. Un outil qui écrit dans le CRM passe par l’informatique ou l’administrateur CRM avant toute utilisation.

Construisez et testez avec des données d’exemple jusqu’à ce que l’outil fonctionne sur le serveur de l’équipe. Une plateforme de déploiement gérée fournissant connexion, secrets et journaux est une option raisonnable pour les équipes qui en prévoient déjà le budget et évaluent leurs fournisseurs.

Un réseau privé signifie que l’outil ne répond pas depuis l’Internet public. L’authentification unique permet aux commerciaux d’utiliser leur compte d’entreprise existant, vérifié par un fournisseur d’identité. Une page de connexion écrite par l’IA reste accessible de partout, et sa solidité dépend du code qui la sous-tend.

Le Vibe Security Radar de Georgia Tech analyse les bases publiques de vulnérabilités et signale les failles attribuées à la signature d’un outil de programmation par IA. Il a dénombré 35 cas pour le seul mois de mars 2026, davantage que pour toute l’année 2025, et cite le contournement de l’authentification parmi les failles détectées (chiffres de la publication Georgia Tech d’avril 2026).

Son chercheur Hanqing Zhao a déclaré : « Lorsqu’un agent construit quelque chose sans authentification, ce n’est pas une faute de frappe. C’est un défaut de conception intégré dès le départ. » J’en déduis que le verrou doit se situer devant l’outil, en dehors du code écrit par l’IA.

Confiez le côté serveur à l’informatique. L’outil fonctionne sur un VPS (un serveur loué entièrement contrôlé par l’équipe), sous un outil de déploiement comme Coolify ou Dokploy. Celui-ci exécute l’application depuis son code et conserve ses variables d’environnement, clé CRM comprise.

Tailscale est le réseau privé le plus rapide à mettre en place, mais utilise son propre serveur de coordination. Headscale, une alternative open source, permet d’héberger vous-même ce serveur ; WireGuard est entièrement auto-hébergé.

Pour la connexion d’entreprise, Authentik convient à la plupart des petites infrastructures internes. Keycloak convient à une entreprise disposant déjà d’un annuaire à raccorder. Un proxy inverse comme Caddy ou Nginx Proxy Manager ajoute HTTPS lorsque la connexion est exposée au Web. Quelle que soit l’infrastructure, une personne nommément désignée doit être responsable du serveur et de l’identifiant d’intégration.

Il lui faut toujours un serveur pour héberger l’ensemble. Notre Linux VPS fournit un accès root, et Coolify, Tailscale, WireGuard, Authentik et Keycloak se déploient en un clic : l’informatique peut ainsi consacrer son temps aux tests. Les emplacements comprennent Francfort et Amsterdam dans l’UE, Londres au Royaume-Uni et plusieurs villes américaines. Soumettez ce choix au DPO ou au responsable de la confidentialité comme élément de décision.

RGPD, CCPA et règlement européen sur l’IA pour les données clients

L’emplacement d’un serveur détermine où réside sa copie des enregistrements. Il ne détermine pas où les services externes stockent les données qu’ils reçoivent. Il ne rend pas à lui seul l’outil conforme à l’une des règles ci-dessous. Au Royaume-Uni, la loi équivalente est le UK GDPR et le régulateur est l’ICO.

RGPD : base légale, sous-traitants et effacement

Si votre entreprise relève du RGPD, la copie des données clients de l’outil est couverte comme tout traitement de données personnelles « automatisé en tout ou en partie ».

Chaque utilisation de données personnelles nécessite une base légale, c’est-à-dire un fondement accepté par le RGPD. Le contrat peut s’appliquer si le traitement est nécessaire à l’exécution d’un contrat avec la personne concernée ou à des mesures précontractuelles demandées par elle. Pour les données CRM, surtout les contacts B2B, l’intérêt légitime peut être plus pertinent et doit être mis en balance avec les droits de la personne. Les deux figurent à l’article 6.

L’outil constitue une nouvelle utilisation de données déjà détenues : demandez au DPO, au responsable de la confidentialité ou au conseil juridique si la base existante la couvre.

Un service externe traitant des données clients pour le compte de l’entreprise est sous-traitant pour ce traitement. Une API d’IA, un service d’analyse ou un hébergeur joue souvent ce rôle, mais le DPO, le responsable de la confidentialité ou le conseil juridique doit confirmer le rôle de chacun. L’article 28 exige des sous-traitants « présentant des garanties suffisantes » et un contrat encadrant le traitement avec chacun. Apportez la liste issue de votre audit des données sortantes.

Lorsque le droit à l’effacement d’un client s’applique au titre de l’article 17, il couvre toutes les copies détenues par l’entreprise, y compris celle de l’outil. C’est pourquoi sa copie doit suivre le CRM.

CCPA : le droit de suppression couvre la copie de l’outil

Les consommateurs californiens peuvent demander à une entreprise soumise au CCPA de supprimer les informations personnelles qu’elle a recueillies à leur sujet, y compris la copie de l’outil et ses exports. Ce droit comporte des exceptions aux articles 1798.105(d) et 1798.145 du Code civil, selon la page CCPA du procureur général de Californie.

Le CCPA impose aussi des contrats écrits avec les prestataires de services et sous-traitants, limitant leur utilisation des informations personnelles. L’entreprise reste chargée de la demande du consommateur, avec l’aide des prestataires ou sous-traitants lorsque cela est requis. Les seuils figurant dans la FAQ déterminent si votre entreprise est couverte.

Règlement européen sur l’IA : la plupart des outils de vente et d’assistance ne sont pas à haut risque

La notation des prospects, les prévisions commerciales, les scores de santé client, les tableaux de bord de campagne et l’automatisation du CRM ne figurent pas parmi les usages à haut risque de l’annexe III du règlement européen sur l’IA. Les exceptions qu’un outil de vente ou d’assistance risque de rencontrer sont précises : l’IA évaluant la solvabilité d’une personne, les risques ou la tarification d’une assurance vie ou maladie, et l’IA déduisant les émotions d’un client à partir de données biométriques.

Le haut risque est la catégorie du règlement soumise aux obligations les plus lourdes. En octobre 2026, les règles visant les systèmes à haut risque de l’annexe III doivent s’appliquer à partir du 2 décembre 2027. Les exigences de transparence de l’article 50 s’appliquent déjà. Au point 5(b), l’annexe III du règlement européen sur l’IA mentionne les systèmes destinés « à évaluer la solvabilité des personnes physiques ou à établir leur note de crédit, à l’exception des systèmes d’IA utilisés pour détecter les fraudes financières ».

Le point 5(c) cite « l’évaluation des risques et la tarification concernant les personnes physiques en matière d’assurance vie et d’assurance maladie ». Un outil effectuant l’une de ces tâches peut être à haut risque et passe par l’informatique et le juridique avant son lancement. Un outil notant la performance de vos propres commerciaux peut relever de la catégorie emploi du point 4(b), une question distincte à traiter avec les RH et le juridique.

Le point 1(c) de la même annexe cite la reconnaissance des émotions, définie à l’article 3 du règlement comme « l’identification ou la déduction des émotions ou des intentions de personnes physiques sur la base de leurs données biométriques ». Un outil d’assistance ou d’appels qui déduit l’humeur d’un client de sa voix ou de son visage peut donc aussi être à haut risque et suit le même parcours auprès de l’informatique et du juridique.

Le règlement vise les systèmes d’IA. Un tableau de bord exécutant du code ordinaire n’en devient pas un simplement parce qu’un outil d’IA a écrit ce code. La question est de savoir si l’outil déployé répond lui-même à la définition d’un système d’IA, et non si l’IA a aidé à écrire son code.

L’absence de haut risque ne signifie pas l’absence de règles. Selon l’article 50, les systèmes qui « interagissent directement avec des personnes physiques » doivent leur signaler qu’elles ont affaire à un système d’IA, sauf si cela est évident. Un chatbot qui parle à vos clients doit toujours indiquer sa nature.

Par ailleurs, l’article 4 impose déjà aux fournisseurs et déployeurs de systèmes d’IA de prendre des mesures pour développer la maîtrise de l’IA chez leur personnel et les autres personnes utilisant ces systèmes pour leur compte.

Foire aux questions

Peut-on créer sans risque un outil CRM avec ChatGPT ou Claude ?

Le construire avec des données d’exemple présente peu de risques. Le risque commence avec l’arrivée de vrais identifiants ou de données clients dans le projet, puis augmente lorsque l’outil est ouvert à d’autres utilisateurs. Avant toute utilisation par un tiers, attribuez à cet outil CRM créé par vibe coding un identifiant CRM restreint, stocké dans les paramètres d’environnement du serveur ou un coffre de secrets et utilisé uniquement côté serveur. Placez aussi l’outil derrière un réseau privé ou la connexion d’entreprise, pour en interdire l’accès aux personnes extérieures. Tant que ces deux conditions ne sont pas remplies, restez sur des données d’exemple.

Le RGPD couvre-t-il un tableau de bord interne que les clients ne voient jamais ?

Si le RGPD s’applique à votre entreprise, un tableau de bord interne détenant des données personnelles clients ne fait pas exception. Le règlement concerne le traitement, pas les personnes qui regardent l’écran, et les données personnelles sont « toute information se rapportant à une personne physique identifiée ou identifiable » selon l’article 4. Son applicabilité et la couverture du nouvel outil par la base légale existante relèvent du DPO, du responsable de la confidentialité ou du conseil juridique.

Les montants d’affaires et les remises sont-ils des données personnelles ?

Le plus souvent, non. Les montants du pipeline, les prévisions et les catalogues de prix sont des données d’entreprise, protégées par les rôles et un journal d’export. Mais un montant ou une remise peut être une donnée personnelle s’il concerne une personne identifiable, par exemple un achat de consommateur ou un entrepreneur individuel, selon la définition de l’article 4.

À quelles entreprises le CCPA s’applique-t-il ?

Aux entreprises à but lucratif exerçant en Californie qui atteignent au moins un seuil. La California Privacy Protection Agency fixe le seuil de chiffre d’affaires ajusté de l’inflation pour 2025 à 26 625 000 $. La page CCPA du procureur général cite les deux autres : acheter, vendre ou partager les informations personnelles d’au moins 100 000 résidents ou foyers californiens, ou tirer au moins 50 % du chiffre d’affaires annuel de la vente ou du partage d’informations personnelles de consommateurs. Votre DPO, responsable de la confidentialité ou conseil juridique confirme si cela vous concerne.