Loi n° 2008-12 : intégrer la conformité CDP dès le cadrage d’un projet SAP ou Salesforce.

Précisons d’emblée ce que ce texte n’est pas : un avis juridique. Nous sommes un cabinet de conseil et de technologie. Ce que nous décrivons ici, c’est la manière dont la loi se traduit dans un projet SAP ou Salesforce, et ce qu’il faut décider, à quel moment, pour ne pas la découvrir trop tard. Les formalités précises relèvent de votre conseil juridique et de la Commission de protection des données personnelles elle-même.

Ce que couvre la loi

La loi n° 2008-12 du 25 janvier 2008 encadre le traitement des données à caractère personnel au Sénégal, c’est-à-dire toute information qui permet d’identifier une personne, directement ou non. Elle désigne un responsable de traitement, l’entreprise qui décide des finalités et des moyens, et lui impose des obligations : une finalité déterminée et légitime, des données proportionnées à cette finalité, une durée de conservation limitée, la sécurité et la confidentialité, et l’information des personnes concernées. Elle reconnaît à ces personnes des droits : être informées, accéder à leurs données, les faire rectifier, s’opposer à certains traitements.

Elle institue une autorité de contrôle, la CDP, auprès de laquelle les traitements font l’objet de formalités préalables. Selon la nature des données et du traitement, il s’agit d’une déclaration ou d’une demande d’autorisation, certaines catégories de données, dites sensibles, appelant un régime plus strict. Enfin, la loi encadre les transferts de données hors du Sénégal, ce qui concerne directement tout projet hébergé à l’étranger ou opéré par un groupe international.

Pourquoi le sujet arrive trop tard

Trois raisons, que nous retrouvons partout. La première est organisationnelle : le projet est porté par la direction financière, la DRH ou la direction commerciale, et personne dans l’équipe projet ne se sent responsable de la conformité. La deuxième est culturelle : on pense que la loi vise les grandes plateformes ou les banques, pas une entreprise industrielle ou une société de services. La troisième est technique : les éditeurs et intégrateurs parlent de sécurité, de sauvegarde et de droits d’accès, et l’équipe conclut que la conformité est couverte. Elle ne l’est pas. La sécurité protège les données ; la conformité justifie qu’on les traite.

Le coût du retard est concret. Un champ « situation de santé » ajouté à une fiche salarié sans finalité déclarée. Une base clients migrée avec des données de prospects collectées sans information. Un hébergement choisi hors du pays sans que la question du transfert ait été posée. Chacune de ces décisions se corrige à la conception en une réunion. Après la mise en production, elle se corrige par une reprise de données, un avenant contractuel ou une nouvelle formalité.

La sécurité protège les données. La conformité justifie qu’on les traite. Un projet qui confond les deux découvre la seconde après la mise en production.

Ce que cela change dans un ERP

Dans SAP S/4HANA, SAP SuccessFactors ou Odoo, les données les plus sensibles sont celles des ressources humaines et de la paie. Le projet doit décider quelles données sont réellement nécessaires : l’état civil et le compte bancaire le sont pour payer ; l’appartenance syndicale, la religion ou les données de santé relèvent d’un régime particulier et n’ont leur place que si une finalité précise le justifie. Il doit fixer les durées de conservation, en tenant compte des obligations de conservation comptable et sociale, puis les mettre en œuvre dans le système : archivage, blocage, suppression. Il doit organiser les droits d’accès par rôle, avec une traçabilité des consultations sur les données sensibles. Et il doit prévoir comment un salarié exerce son droit d’accès, sans que cela passe par une extraction manuelle improvisée.

Les fournisseurs et les clients personnes physiques sont aussi concernés. Un artisan sous-traitant ou un client particulier est une personne au sens de la loi. Le module achats et le module ventes traitent donc des données personnelles, avec les mêmes questions de finalité, de durée et d’accès.

Ce que cela change dans un CRM

Salesforce Sales Cloud, Service Cloud et Marketing Cloud sont conçus pour collecter, enrichir et exploiter des données de contact. C’est leur raison d’être, et c’est ce qui appelle une vigilance particulière. Trois sujets dominent. Le premier est la collecte : d’où viennent les contacts, ont-ils été informés, un fichier acheté ou importé d’un ancien outil est-il utilisable ? Le deuxième est le scoring et la segmentation : classer des personnes selon leur valeur ou leur comportement est un traitement à part entière, qui doit être déclaré et expliqué, et dont les personnes peuvent contester les effets. Le troisième est la campagne : l’envoi automatisé de messages par SMS, e-mail ou WhatsApp suppose une base légale, une possibilité de refus simple et le respect de ce refus dans tous les canaux.

Un CRM bien conçu porte ces règles dans sa donnée : la source du contact, la date et le mode de son information, ses choix de communication, canal par canal, et la date au-delà de laquelle il doit être archivé. Ce n’est pas un module de conformité. C’est un modèle de données pensé dès le cadrage.

Transferts et hébergement

La question de l’hébergement est souvent tranchée pour des raisons de coût ou de performance, sans que le transfert de données soit examiné. Or un CRM en cloud public, un ERP hébergé par un groupe hors du Sénégal, un centre de services partagés dans un autre pays, ou un prestataire de support qui accède à distance à la base de production sont autant de situations qui peuvent constituer un transfert. Le projet doit les inventorier, en discuter avec son conseil juridique, et intégrer les clauses nécessaires dans les contrats avec les éditeurs et les prestataires, avant la signature. Nous traitons cette dimension dans notre offre cloud, où la localisation des données est un critère de choix au même titre que la latence et le coût en devises.

Checklist par phase de projet

• Cadrage. Nommer un responsable de la conformité dans l’équipe projet. Inventorier les traitements que le futur système portera et leurs finalités. Identifier les données sensibles. Poser la question de l’hébergement et des transferts. Consulter le conseil juridique sur les formalités à engager auprès de la CDP et sur leur calendrier.
• Conception. Limiter les champs aux données nécessaires. Définir les durées de conservation et les règles d’archivage. Concevoir les rôles et les habilitations. Prévoir dans le modèle de données la source, l’information et les choix des personnes. Décrire comment les droits d’accès, de rectification et d’opposition seront traités.
• Réalisation. Paramétrer les habilitations et la traçabilité. Chiffrer ou masquer les données sensibles dans les environnements de test. Vérifier que les interfaces, notamment entre SAP et Salesforce, ne dupliquent pas de données sans nécessité.
• Reprise des données. Trier avant de migrer. Une donnée dont la finalité ou l’origine ne peut être justifiée ne doit pas entrer dans le nouveau système. C’est l’occasion, rare, de purger.
• Mise en production. S’assurer que les formalités sont accomplies ou engagées. Informer les personnes concernées, salariés et clients, du nouveau traitement. Former les utilisateurs aux règles d’accès et aux demandes des personnes.
• Exploitation. Revoir régulièrement les habilitations. Appliquer les purges prévues. Tenir à jour l’inventaire des traitements à chaque évolution fonctionnelle. Intégrer ces revues dans le contrat de support et TMA.

Le cas des groupes de l’UEMOA

Un groupe présent dans plusieurs États de l’union partage une monnaie et un droit des affaires harmonisé. Il ne partage pas une autorité de protection des données. Chaque pays a sa loi et son autorité, avec des formalités, des délais et des exigences qui diffèrent. Un CRM régional ou un ERP de groupe doit donc être conçu pour que chaque filiale reste responsable de ses traitements, avec des données cloisonnées par pays quand la loi locale l’exige, et un dossier de conformité par État. La tentation d’une base unique, régie par la règle d’un seul pays, est forte. Elle ne tient pas.

La conformité n’est pas un frein aux projets. C’est une exigence de conception, comme la performance ou la sécurité, qui se paie au cadrage et rapporte à l’exploitation. Notre offre sécurité & risques IT l’intègre dans nos programmes SAP et Salesforce, depuis le premier atelier.