Pourquoi bâtir sa GRU sur un socle CRM ?
Deux arguments circulent contre le CRM dans le secteur public : les citoyens ne sont pas des clients, et le CRM ne serait pas conforme au RGPD. Examinons-les au regard des besoins réels des collectivités et de ce que dit vraiment la CNIL.
Décisions
Ce que cet article vous aide à décider
Le débat sémantique entre client et citoyen masque la vraie question : comment tracer et suivre efficacement une demande. La CNIL, elle, n'interdit pas le référentiel usager : elle exige un cloisonnement, une gestion des droits et des identifiants sectoriels, et un CRM sait faire les trois. La traçabilité, exigée par le RGPD lui-même, est d'ailleurs une fonction native du CRM et non une surcouche à développer. Redévelopper un socle, c'est refaire ce qui existe et devoir en assumer seul les évolutions technologiques.
Une théorie d'inadaptation du CRM à la gestion de la relation usagers circule auprès des acteurs publics. Elle est portée par des éditeurs de solutions de GRC qui ont développé leur produit intégralement, sans s'appuyer sur un socle existant.
« Les citoyens ne sont pas des clients », et après ?
Assimiler les citoyens à des clients a une connotation consumériste qui peut sembler de mauvais aloi s'agissant de service public. Certains termes, comme celui de productivité, sont mal perçus par une partie des acteurs publics et prennent vite un tour politique. Le sujet devient clivant par principe.
C'est sans doute l'effet recherché par ceux qui brandissent cette distinction de vocabulaire.
Or la question n'est pas la manière dont on considère l'usager. Elle est la manière de traiter ses demandes et de les suivre. Sur ce terrain, l'usager rejoint sans conteste le customer du sigle CRM sur quatre fonctions.
| Fonction native du CRM | Ce qu'elle apporte à une collectivité |
|---|---|
| Traçabilité | Qui a fait quoi et quand : actions de l'usager, échanges, instruction par les agents, flux avec les outils métiers |
| Multicanal et cross-canal | Une vision de la relation quel que soit le canal de sollicitation, du guichet au réseau social |
| Qualité de service | Délais paramétrables, notifications automatiques aux usagers comme aux agents |
| Information proactive | Prévenir plutôt que subir des appels : ouverture d'une campagne de subvention, annulation d'un événement |
La traçabilité
C'est l'un des premiers principes du CRM. Elle couvre les actions de l'usager sur son compte, les échanges avec lui quel que soit leur support, les actions des agents lors de l'instruction, et les interactions avec les outils métiers.
La traçabilité est une exigence du RGPD, pas un obstacle
Un point mérite d'être rappelé à ceux qui opposent CRM et RGPD : la traçabilité est requise en matière de conformité, ne serait-ce que pour la tenue des registres.
On peut évidemment développer soi-même ce volet dans un logiciel maison. Mais on dépense alors du temps et de l'énergie à refaire ce qu'un CRM fait très bien en standard. Le raisonnement vaut pour toutes les fonctions qui suivent.
Le multicanal
L'objectif d'un CRM est de donner une vision globale de la relation, quel que soit le canal de sollicitation. Ces canaux sont nombreux et se juxtaposent : réseaux sociaux, appels, courriers, e-mails, services en ligne, interpellations directes au guichet ou auprès d'un élu lors d'un conseil de quartier.
Limiter la GRC aux seuls flux de téléservices est, sur ce point, totalement insuffisant.
Quiconque dirige une commune ou un département sait aussi que l'usager n'apprécie pas de constater que l'élu qui le reçoit, ou l'agent d'accueil qu'il interroge, ignore tout de ses demandes en cours. La fonction du CRM est précisément de collecter et centraliser autour d'un référentiel usagers l'ensemble des demandes et interactions, puis de les restituer sur un ou plusieurs canaux.
La qualité de service
Même dans le privé, l'objectif d'un CRM n'est pas seulement de faire du profilage commercial. Il est d'abord d'améliorer le service rendu par une meilleure maîtrise des processus d'instruction.
Informer l'usager en temps réel sur l'avancement de son dossier, c'est éviter des appels entrants, des courriers et des recherches fastidieuses pour y répondre. C'est désengorger les centres de contact et soulager les métiers.
La saisine par voie électronique, encadrée par le Code des relations entre le public et l'administration, rappelle d'ailleurs que l'usager doit être informé et que l'instruction doit être suivie et tracée. Y compris dans les services publics.
L'information proactive
Prévenir une association que la campagne de subvention qu'elle a sollicitée l'an dernier vient de s'ouvrir, est-ce du marketing ou un service rendu ? Envoyer un SMS aux inscrits d'un événement annulé, est-ce une intrusion ou une attention ?
Ce n'est jamais l'outil qu'il faut mettre en cause, mais l'usage qu'on en fait. Utilisés avec discernement et dans le respect de la finalité de collecte des données, les modules de campagne d'un CRM rendent un vrai service. Ce qui nous amène au second argument.
Passer à l'action
Votre projet de GRU repose-t-il sur un socle ?
Nous vous montrons comment le cloisonnement, les habilitations par profil et la traçabilité se paramètrent concrètement, sur vos propres dispositifs.
CRM et RGPD : ce que dit vraiment la CNIL
Selon ses détracteurs, le CRM serait un outil non conforme au RGPD. On note là encore une confusion entre l'outil et son éventuelle utilisation non conforme.
Le reproche précis est le suivant : le CRM offrirait à la collectivité une vision globale des demandes qui contreviendrait au principe de cloisonnement des données. Allons voir le texte.
Les trois exigences réelles
Dans sa doctrine sur les téléservices, la CNIL demande au responsable de traitement de maintenir un cloisonnement des informations personnelles selon la finalité de leur collecte. Elle précise que cette étanchéité passe notamment par une politique de gestion des droits des personnes habilitées à accéder aux données en fonction de leurs missions. Elle ajoute qu'une collectivité proposant plusieurs démarches en ligne doit générer un identifiant par service public.
| Ce que demande la CNIL | Comment un socle CRM y répond |
|---|---|
| Cloisonner les données selon la finalité de collecte | Paramétrage de la visibilité des demandes et documents par dispositif |
| Gérer les droits des agents selon leurs missions | Moteur d'habilitations par profil métier, fonction native du CRM |
| Générer un identifiant par service public | Portail chapeau, avec des identifiants usagers propres à chaque métier |
C'est le point que les détracteurs du CRM ne relèvent jamais : la CNIL décrit une politique de gestion des droits, c'est-à-dire exactement ce qu'un CRM sait faire. Un CRM est, techniquement, un moteur d'habilitations autant qu'une base de données.
L'absurdité que produit la lecture inverse
Imaginons qu'un usager appelle un centre de contact pour savoir où en est son dossier. L'agent doit-il répondre qu'un service de la collectivité connaît sans doute la réponse, mais qu'il n'a pas le droit de la lui donner, et que ce service ne répond pas directement aux usagers ?
C'est à ce genre de situation qu'aboutit une dialectique biaisée du RGPD.
Les exceptions se gèrent par paramétrage
Certains dossiers sensibles, en matière d'action sociale notamment, doivent pouvoir être écartés de la vision de synthèse. Il est également possible de gérer des droits en consultation avec un niveau de détail configurable, en n'affichant par exemple que l'objet, la date de dépôt et l'état générique d'une demande.
La conformité se joue au-dessus du socle
En matière de RGPD, ce n'est pas le CRM qui doit être conforme. Ce sont les procédures et les mécanismes mis en place dans la solution finale : le cloisonnement des données par profil métier, le portail chapeau avec des identifiants usagers propres à chaque métier, la purge des demandes clôturées après un délai paramétrable, la désactivation des comptes inactifs, la gestion du droit à l'oubli, la suppression par l'usager de ses demandes et de son compte, et le recueil de l'accord explicite au niveau des téléservices avec indication de la finalité de collecte.
En tant qu'éditeur d'une solution bâtie sur un socle CRM, nos équipes implémentent ces mécanismes sous forme d'un module RGPD qui surcharge le socle, afin d'assurer la conformité et l'homologation des téléservices.
Loin d'être un frein, le CRM apporte ici un avantage décisif : il trace les actions RGPD elles-mêmes, effacements, désactivations et archivages compris. Ce qui est précisément ce que le règlement attend d'un responsable de traitement.
Restitutions et anonymisation
Dans le même esprit, les demandes des usagers n'ont pas vocation à être conservées indéfiniment dans une base globale à des fins d'analyse.
Il reste tout à fait possible, avec un CRM, de construire une base infocentre anonymisée destinée aux restitutions et aux études statistiques, y compris pluriannuelles. Cette fonctionnalité est implémentée en standard dans Open GRU, qui s'appuie sur un socle SuiteCRM.
Socle ou développement sur mesure : l'analogie du CMS
Je terminerai par un parallèle avec l'histoire des sites internet.
Il y a une quinzaine d'années, alors que je dirigeais une agence web, le débat portait sur la pertinence de s'appuyer ou non sur un CMS pour concevoir un site. Les anti-CMS étaient nombreux, majoritaires même. Faute d'avoir fait ce choix dans leur offre, ils multipliaient les arguments techniques, pratiques ou philosophiques pour expliquer en quoi un CMS n'était pas adapté.
Aujourd'hui, plus personne n'envisage de développer un site sans s'appuyer sur WordPress, Drupal, Typo3 ou équivalent. Ces outils, le plus souvent open source, bénéficient d'une force de développement collective, d'un périmètre fonctionnel enrichi par les contributions, et d'une capacité d'adaptation aux mutations technologiques indispensable.
Le CRM est à la GRU ce que le CMS est à la gestion de contenus : un socle qui intègre nativement les fonctions essentielles et qui évolue au rythme des usages et des technologies, du responsive à l'interopérabilité. L'effort des éditeurs qui s'appuient dessus porte uniquement sur les surcouches d'adaptation nécessaires, dans notre cas la gestion d'usagers plutôt que de clients.
Le gain se mesure moins au développement initial qu'à la maintenance et aux évolutions.
Ce que cela change pour une collectivité
Passez à l'action
Prêt à unifier votre relation usager ?
Découvrez comment Open CRM centralise les demandes issues de tous vos canaux, avec un référentiel usager unique et des habilitations par profil métier. Chaque demande tracée de bout en bout, pour une vision d'ensemble côté direction.
Demander une démonstrationSans engagement · 20 min avec un expert GRU
Questions fréquentes
Un CRM est-il conforme au RGPD ?
La question est mal posée. La conformité ne se joue pas au niveau du socle mais des mécanismes mis en place au-dessus : cloisonnement par profil, gestion des durées de conservation, droit à l'oubli, recueil du consentement. Un CRM facilite ces mécanismes puisqu'il trace nativement les actions réalisées.
La CNIL interdit-elle un référentiel usager unique ?
Non. Elle exige un cloisonnement des données selon la finalité de collecte, une politique de gestion des droits des agents habilités, et un identifiant par service public pour les téléservices. Ces exigences se satisfont par paramétrage, pas par la multiplication des bases.
Quelle différence entre GRC et GRU ?
Les deux sigles désignent la gestion de la relation avec les usagers d'un service public, l'un parlant de citoyens, l'autre d'usagers. La différence réelle tient moins au vocabulaire qu'à l'architecture : certaines solutions se limitent aux flux de téléservices, d'autres couvrent l'ensemble des canaux autour d'un référentiel.
Pourquoi ne pas développer sa propre solution ?
Parce qu'on refait alors ce qu'un socle fournit en standard, et qu'il faut ensuite en assumer seul la maintenance et les évolutions technologiques.
Sur quel socle repose Open GRU ?
Sur SuiteCRM, socle open source, complété par les surcouches métier nécessaires au secteur public et par un module RGPD dédié.
CNIL, Téléservices et protection de la vie privée ; Code des relations entre le public et l'administration (saisine par voie électronique) ; règlement général sur la protection des données. Article initialement publié en 2020, mis à jour en 2026.
