Variables de process dans les logs Camunda : la fuite RGPD que personne ne modélise

Un consultant Camunda manipule les variables de process comme un outil de travail : elles portent l'état métier d'une instance, circulent entre les activités, alimentent les conditions de gateways et les règles DMN. Ce qu'on oublie facilement, c'est que ces variables ne restent pas confinées dans le moteur. Elles laissent des traces partout.

Elles sont d'abord persistées dans l'historique : Camunda conserve la valeur des variables au fil de l'exécution, pour l'audit et le rejeu. Elles apparaissent ensuite dans les logs applicatifs, dès qu'un worker journalise son payload ou qu'une exception remonte le contexte d'exécution. Elles sont enfin visibles dans les outils d'opération, où un administrateur peut inspecter une instance et lire le contenu des variables.

Quand ces variables contiennent un nom, un IBAN, un numéro de sécurité sociale, une donnée de santé ou tout autre élément identifiant, vous ne manipulez plus seulement de la donnée métier : vous manipulez des données à caractère personnel. Et à cet instant, le RGPD entre dans le périmètre de votre modélisation.

Le piège tient à la durée de vie de ces traces. Une variable de process n'est pas une valeur éphémère qui s'évapore à la fin de l'instance. Camunda conserve, dans ses tables d'historique, l'évolution des variables au fil de l'exécution, pour permettre l'audit, le rejeu et l'analyse a posteriori. Cette même donnée a pu, en parallèle, être journalisée par un worker au moment où il traitait son job, par un message d'erreur qui a remonté le contexte complet de l'instance, ou par un export d'historique vers un système d'observabilité. Une seule donnée personnelle peut ainsi se retrouver dupliquée dans trois ou quatre emplacements, chacun avec sa propre politique de rétention et son propre niveau d'accès. C'est cette dispersion silencieuse qui transforme une variable anodine en risque de conformité.

Trois principes du Règlement général sur la protection des données touchent directement la façon dont vous concevez un processus.

La minimisation des données

Vous ne devez traiter que les données strictement nécessaires à la finalité. Transposé au BPMN : transporter un objet métier complet dans une variable de process, alors que seul un identifiant serait nécessaire, contrevient à ce principe. Chaque donnée personnelle superflue dans une variable est une donnée exposée sans raison.

La limitation de conservation

Les données ne doivent pas être conservées plus longtemps que nécessaire. Or l'historique Camunda conserve par défaut les variables bien au-delà de la fin de l'instance, selon la configuration de rétention. Sans politique de purge alignée sur la finalité, vous fabriquez un stock de données personnelles dormant.

La protection dès la conception

Le RGPD impose le privacy by design : la protection des données doit être intégrée dès la conception du traitement, pas ajoutée après coup. C'est exactement le moment où vous modélisez. Choisir de ne pas stocker une donnée sensible en clair, prévoir le chiffrement ou la tokenisation, c'est faire du privacy by design dans le BPMN.

Le cas particulier des données sensibles

Le Règlement distingue les données personnelles ordinaires des catégories particulières : santé, orientation, données biométriques. Pour une assurtech, un processus de souscription santé peut faire transiter un état de santé déclaré dans une variable de process. Ces données bénéficient d'un régime renforcé : leur traitement est en principe interdit, sauf exception, et leur exposition accidentelle dans un historique ou un log constitue un manquement d'une gravité supérieure. Un consultant qui modélise un parcours de souscription santé sans poser la question du traitement de ces variables prend un risque disproportionné par rapport au gain de simplicité.

En modélisant un processus, vous prenez des décisions de protection des données. Le RGPD ne s'arrête pas à la porte du moteur d'orchestration.

Sur le plan strictement juridique, c'est le responsable de traitement, c'est-à-dire le client, qui répond du RGPD devant l'autorité de contrôle. Vous, consultant, intervenez comme prestataire. Mais cette répartition ne vous met pas à l'abri.

Si une fuite de données survient parce que des variables sensibles transitaient en clair dans les logs, et que cette exposition découle d'un choix de modélisation que vous avez recommandé, le client se retournera contre vous. Il vous reprochera un manquement à votre devoir de conseil : un consultant compétent aurait dû alerter sur le risque, proposer une alternative, ou refuser de modéliser un transport de donnée sensible en clair.

La frontière de votre responsabilité se joue, là encore, sur l'écrit. Avez-vous signalé que telle variable contenait une donnée personnelle exposée dans l'historique ? Avez-vous préconisé une stratégie de minimisation ou de chiffrement ? Un consultant qui a documenté ses alertes RGPD se défend ; celui qui a livré sans un mot porte le risque. Pour comprendre l'articulation entre faute professionnelle et violation de données, notre dossier assurance cyber détaille les mécanismes en jeu.

Quelques pratiques limitent drastiquement l'exposition des données personnelles dans un processus Camunda.

• Ne transporter que des identifiants dans les variables, et résoudre la donnée complète à la volée dans le worker, sans la persister dans le process.
• Chiffrer ou tokeniser les variables sensibles qui doivent transiter, de sorte qu'elles n'apparaissent jamais en clair dans l'historique ou les logs.
• Encadrer la journalisation des workers pour qu'ils ne déversent jamais le payload complet d'une variable dans les logs applicatifs.
• Aligner la rétention de l'historique sur la durée de conservation autorisée par la finalité du traitement.
• Documenter chaque variable contenant une donnée personnelle et la mesure de protection associée.

Ces réflexes ne relèvent pas du superflu : ils constituent l'état de l'art attendu d'un consultant Camunda intervenant chez une fintech, une assurtech ou tout client traitant des données personnelles à grande échelle.

Même avec les meilleurs réflexes, le risque zéro n'existe pas. Une variable oubliée, un log trop bavard, une configuration de rétention héritée d'un autre projet, et une violation de données peut survenir. Lorsque cette violation découle de votre prestation, le client peut vous mettre en cause pour le préjudice subi.

L'option Cyber de la RC Pro Insurio est conçue pour ce cas. Elle couvre les conséquences d'une violation de données imputable à votre intervention : frais de gestion de l'incident, accompagnement juridique, conséquences financières des réclamations liées à l'exposition de données personnelles. Couplée à la garantie cyber dédiée, elle complète la responsabilité civile professionnelle classique, qui se concentre sur le préjudice financier des bugs d'orchestration.

Pour un consultant Camunda intervenant sur des processus chargés de données sensibles, cette extension n'est pas un confort : c'est l'alignement de votre couverture sur la réalité de votre exposition. La RC Pro avec option Cyber démarre à un tarif accessible dès le profil freelance, à partir de 18,90€/mois pour la base, l'extension cyber étant dimensionnée selon la sensibilité des données traitées.