Un CRM installé dans une administration n'est pas un CRM d'entreprise auquel on aurait remplacé le mot « client » par le mot « usager ». Le vocabulaire change, mais surtout le cadre change : base légale du traitement, désignation d'un délégué à la protection des données, homologation de sécurité, lieu d'hébergement, accessibilité du service, durée de conservation, et jusqu'à la manière d'acheter le logiciel. Un projet qui ignore l'un de ces points se bloque rarement à la démonstration commerciale, mais presque toujours au moment de la mise en production.
Je ne suis pas juriste. Mon métier, c'est le web et la mesure, et je croise ce sujet quand une structure publique ou para-publique veut piloter sa relation usager comme on pilote un tunnel de conversion. Ce que je constate le plus souvent, c'est que le choix de l'outil est fait avant l'analyse du cadre, alors que c'est l'inverse qui coûte le moins cher. Cet article résume donc les règles applicables telles qu'elles sont publiées, avec les liens vers les textes. Il ne contient volontairement aucune promesse chiffrée de gain de productivité : ces gains dépendent de l'organisation du service, pas de la licence.
Ce qu'un CRM apporte réellement à une relation usager
Dans une collectivité ou un établissement public, un CRM sert d'abord à trois choses : rassembler en un point les sollicitations arrivées par des canaux différents (guichet, téléphone, formulaire en ligne, courriel), garder la trace de ce qui a été répondu, et produire des indicateurs sur les demandes récurrentes. C'est sur ce troisième point que la valeur est la plus nette : savoir que 40 % des appels d'un mois portent sur le même sujet oriente une refonte de page bien mieux qu'une réunion d'arbitrage.
Deux limites méritent d'être posées dès le départ. D'une part, un CRM ne remplace pas un système d'information métier : il documente la relation, pas l'instruction du dossier. D'autre part, la centralisation des historiques crée mécaniquement une base de données sensible, souvent plus riche que les applications métier elles-mêmes, puisqu'elle agrège les motifs de contact d'une même personne. C'est précisément ce qui déclenche l'essentiel des obligations qui suivent.
RGPD : base légale, registre et DPO
Pour une autorité publique, le consentement est rarement la bonne base légale. La CNIL rappelle que le traitement mis en œuvre par un organisme public à l'égard de ses usagers relève en principe de la mission d'intérêt public prévue à l'article 6.1.e du RGPD, et que cette mission ne se présume pas : elle doit être prévue par un texte, européen ou national. Conséquence pratique : il faut pouvoir dire, traitement par traitement, quel texte fonde la collecte, quelles données sont nécessaires et à qui elles peuvent être communiquées.
La désignation d'un délégué à la protection des données n'est pas une option. La CNIL indique sur sa page dédiée aux collectivités territoriales que le RGPD impose à toute structure publique de désigner un DPO, et que le registre des traitements doit recenser l'ensemble des activités concernées. Beaucoup de petites communes mutualisent ce rôle, via un syndicat mixte ou un centre de gestion. Dans un projet CRM, le DPO doit être associé avant l'écriture du cahier des charges : c'est lui qui tranchera les questions de durées, de profilage, de destinataires et d'analyse d'impact.
Sécurité : le référentiel général de sécurité et l'homologation
Les téléservices des autorités administratives relèvent du référentiel général de sécurité, dont le cadre juridique repose sur l'ordonnance n° 2005-1516 du 8 décembre 2005, le décret n° 2010-112 du 2 février 2010 et l'arrêté du 13 juin 2014 qui approuve le référentiel. L'ANSSI y décrit les fonctions de sécurité attendues : identification, signature électronique, horodatage, confidentialité des échanges.
L'obligation la plus structurante est l'homologation de sécurité. Concrètement, l'autorité administrative conduit une analyse de risques, détermine le niveau de sécurité adapté à son téléservice, puis atteste formellement que le risque résiduel est accepté. Ce n'est pas un tampon : c'est une décision prise par un responsable identifié, révisable, et qui suppose un dossier. Si votre CRM expose un portail usager, il entre dans ce périmètre. Prévoyez le budget et le délai correspondants dès le début, pas après la recette.
Hébergement : la doctrine « cloud au centre »
La doctrine d'utilisation de l'informatique en nuage par l'État publiée par la DINUM pose un principe simple : pour tout nouveau projet numérique, quelle que soit sa taille, une solution cloud doit être recherchée. Elle distingue le cloud interne de l'État et les offres commerciales, et impose une condition ferme pour les données les plus sensibles, notamment celles dont la divulgation serait susceptible d'engendrer une atteinte à l'ordre public : recours à une offre qualifiée SecNumCloud, immunisée contre les accès d'autorités tierces hors Union européenne.
L'illustration la plus récente est le choix d'hébergeur de la Plateforme des données de santé. Dans une actualité publiée le 8 juin 2026, la DINUM indique que le GIP a retenu Scaleway à l'issue d'une analyse fondée sur plus de 350 critères de sécurité, de résilience, de performance et de conformité, la DINUM intervenant en appui technique sans prendre la décision. Retenez la méthode plus que le nom : une grille de critères écrite avant la consultation, et une exigence de souveraineté proportionnée à la sensibilité des données.
Accessibilité : le RGAA n'est pas facultatif
L'article 47 de la loi n° 2005-102 du 11 février 2005 impose l'accessibilité des services de communication au public en ligne. Le champ d'application publié sur accessibilite.numerique.gouv.fr couvre les personnes morales de droit public, les organismes de droit privé chargés d'une mission d'intérêt général, et les entreprises privées dont le chiffre d'affaires annuel réalisé en France dépasse 250 millions d'euros. Il vise les sites, les applications mobiles, les progiciels et, point souvent oublié, les intranets et extranets : un CRM utilisé uniquement par des agents reste concerné.
La version en vigueur est le RGAA 4.1.2, la version 4 ayant été arrêtée conjointement le 20 septembre 2019 ; le site indique qu'une version 5 est en cours de rédaction, avec une publication annoncée pour la fin 2026. Les obligations documentaires sont précises : déclaration d'accessibilité, mention de conformité, schéma pluriannuel de mise en accessibilité.
Le niveau réel reste faible. En annonçant le 28 mai 2026 la publication d'un guide de l'accessibilité numérique destiné aux acheteurs publics, la DINUM indique que 9 % seulement des démarches administratives essentielles de l'État sont entièrement conformes au RGAA. Ce guide propose des clauses types pour les progiciels, les développements spécifiques et les prestations intellectuelles, ainsi que des critères d'attribution, des modalités d'audit et des pénalités. C'est le document à ouvrir avant de rédiger un cahier des charges CRM, car exiger l'accessibilité après notification revient à la payer deux fois. Si le sujet vous concerne aussi côté site public, il rejoint directement le travail d'un audit UX.
Archivage et durées de conservation
Une base CRM ne se purge pas au hasard. La CNIL décrit un cycle de vie en trois temps : base active, archivage intermédiaire, archivage définitif. Sa page sur les durées de conservation précise que les données en archivage intermédiaire doivent être séparées physiquement ou logiquement de la base active et réservées à des personnes habilitées. Le guide associé a été élaboré avec le service interministériel des Archives de France, afin d'articuler les obligations du RGPD avec celles du code du patrimoine.
C'est le point de friction classique du secteur public : le RGPD impose de ne pas conserver indéfiniment, le code du patrimoine interdit d'éliminer des archives publiques sans visa. Traduction opérationnelle pour un CRM : la fonctionnalité « supprimer » ne suffit pas, il faut un paramétrage de purge par finalité, un statut d'archive intermédiaire, et un export pérenne pour ce qui relève du versement.
Acheter le logiciel : seuils et procédure
Le mode d'achat dépend du montant estimé du besoin sur la durée totale du marché, reconductions comprises. Les seuils ci-dessous figurent sur la fiche service-public.gouv.fr consacrée aux seuils des marchés publics, vérifiée le 21 août 2026.
| Situation | Fournitures et services | Travaux |
|---|---|---|
| Dispense de publicité et de mise en concurrence | moins de 60 000 € | moins de 100 000 € |
| Procédure formalisée — État, pouvoirs adjudicateurs centraux | à partir de 140 000 € | à partir de 5 404 000 € |
| Procédure formalisée — collectivités et autres pouvoirs adjudicateurs | à partir de 216 000 € | à partir de 5 404 000 € |
| Procédure formalisée — entités adjudicatrices | à partir de 432 000 € | à partir de 5 404 000 € |
Deux réflexes utiles. D'abord, additionner licences, intégration, reprise de données, formation et maintenance : c'est la valeur totale qui détermine la procédure, pas le prix de la première année. Ensuite, écrire les exigences de conformité dans le cahier des charges, pas dans un courriel : accessibilité RGAA, hébergement et qualification attendue, réversibilité et format d'export, localisation des données et des sauvegardes, engagement du sous-traitant au sens de l'article 28 du RGPD, et modalités d'audit.
L'ordre dans lequel je prendrais le sujet
Sur un projet de ce type, je commence toujours par cartographier les canaux de contact réels et le volume associé, avant de parler d'outil. Vient ensuite l'analyse juridique avec le DPO, puis l'arbitrage d'hébergement, puis seulement la consultation. La mesure arrive en dernier mais doit être prévue dès le départ : sans indicateurs définis en amont, un CRM public devient une archive de tickets que personne n'exploite. C'est la même logique que pour un pilotage webmarketing ou pour la création d'un site professionnel : on décide ce qu'on veut observer avant de choisir l'outil qui observera.
Questions fréquentes
Un CRM est-il obligatoire dans une administration ?
Non, aucun texte n'impose de CRM à une administration. Ce sont les obligations générales qui s'appliquent dès qu'un traitement de données personnelles est mis en œuvre : base légale, registre, sécurité, accessibilité, conservation limitée. Le choix d'un CRM est une décision d'organisation, pas une obligation réglementaire.
Faut-il le consentement des usagers pour alimenter un CRM public ?
En principe non. Pour une autorité publique agissant vis-à-vis de ses usagers, la base légale pertinente est le plus souvent la mission d'intérêt public prévue à l'article 6.1.e du RGPD. Cette mission doit être prévue par un texte européen ou national, et l'organisme doit pouvoir démontrer la validité de cette base légale.
Un CRM hébergé hors de France est-il interdit pour une administration ?
Ce n'est pas une interdiction générale, mais une exigence proportionnée à la sensibilité des données. La doctrine « cloud au centre » de la DINUM impose le recours à une offre qualifiée SecNumCloud, immunisée contre les accès d'autorités tierces, pour les données sensibles ou dont la divulgation porterait atteinte à l'ordre public. Pour les autres traitements, les règles de transfert hors Union européenne du RGPD s'appliquent.
Le RGAA s'applique-t-il à un outil utilisé uniquement par les agents ?
Oui. Le champ d'application publié par l'État couvre les sites, applications mobiles, progiciels, mais aussi les intranets et extranets des organismes concernés. Un CRM interne doit donc être accessible, et l'exigence se traduit par des clauses contractuelles et des audits prévus dans le marché.
Faut-il lancer un appel d'offres pour acheter un CRM ?
Cela dépend du montant total estimé du besoin, reconductions et prestations associées comprises. En dessous de 60 000 euros hors taxes pour des fournitures et services, l'acheteur peut se dispenser de publicité et de mise en concurrence ; la procédure formalisée devient obligatoire à partir de 140 000 euros pour l'État et de 216 000 euros pour les collectivités. Ces montants figurent sur la fiche officielle des seuils, vérifiée en août 2026.
Combien de temps peut-on conserver les données d'un usager dans un CRM ?
Il n'existe pas de durée unique : elle se détermine finalité par finalité, en fonction de l'objectif du traitement, des obligations légales et d'un éventuel contentieux. La CNIL distingue base active, archivage intermédiaire et archivage définitif, l'archivage intermédiaire devant être séparé de la base active et réservé à des personnes habilitées. Dans le secteur public, ces durées doivent s'articuler avec les règles d'archives publiques du code du patrimoine.