Qui est responsable de quoi
Le règlement général sur la protection des données (RGPD, ou GDPR/AVG) distingue le responsable de traitement, qui décide des finalités et des moyens, et le sous-traitant, qui traite les données pour son compte et selon ses instructions. Dans le cas d'une application communale, la commune est en principe responsable de traitement pour les données de ses habitants ; l'éditeur de l'application agit comme sous-traitant, puis fait lui-même appel à des sous-traitants ultérieurs (hébergeur, service d'envoi de SMS ou d'e-mails, fournisseurs de notifications, cartographie, modèle d'IA le cas échéant).
- Un prestataire peut aussi être responsable de traitement pour ses propres finalités (par exemple les données de son site web ou de la facturation). Faites-le préciser dans le contrat.
- Si l'éditeur utilise les données d'habitants pour ses propres fins (statistiques commerciales, publicité, entraînement de modèles), il sort de son rôle de sous-traitant : c'est à refuser, ou à encadrer très strictement.
- Les rôles se qualifient selon la réalité des décisions, pas selon les étiquettes du contrat : vérifiez que ce qui est écrit correspond à ce qui se passe.
L'accord de sous-traitance (article 28)
Le RGPD impose un contrat écrit entre le responsable de traitement et le sous-traitant (article 28, à vérifier pour la numérotation exacte dans votre version de travail). Il doit au minimum encadrer les points suivants.
- L'objet, la durée, la nature et la finalité du traitement, les types de données et les catégories de personnes concernées.
- Le traitement uniquement sur instruction documentée de la commune, y compris pour les transferts hors de l'Union.
- La confidentialité du personnel autorisé.
- Les mesures de sécurité (chiffrement, contrôle d'accès, journalisation, sauvegardes, isolation entre communes clientes).
- Le recours à des sous-traitants ultérieurs : liste communiquée, autorisation préalable (générale ou spécifique), information en cas de changement, même niveau d'obligations imposé en cascade.
- L'aide à la commune pour répondre aux demandes d'exercice de droits, aux analyses d'impact et aux violations de données.
- La notification des violations de données dans un délai court et précisé.
- La restitution ou la suppression des données à la fin du contrat, avec un format et un délai précis.
- Un droit d'audit ou, à défaut, la mise à disposition d'informations probantes.
Lisez aussi les annexes : la liste des sous-traitants ultérieurs et leurs pays, la description des mesures de sécurité. Une annexe vide ou trop vague est un signal d'alerte. Les modèles fournis par un éditeur, par exemple l'accord de sous-traitance de Placette, doivent être relus par votre juriste ou votre DPO avant signature.
Base légale : mission d'intérêt public ou consentement ?
Tout traitement a besoin d'une base légale (article 6). Pour une autorité publique, la base principale est la mission d'intérêt public ou l'exercice de l'autorité publique : informer les habitants des travaux, gérer les signalements sur l'espace public, publier l'agenda. L'« intérêt légitime » est en principe exclu pour les traitements que la commune effectue dans l'exercice de ses missions (à vérifier selon le droit national).
- Notifications push, SMS, e-mails : le consentement de l'habitant est la solution la plus claire, à la fois pour le RGPD et pour les règles nationales issues de la directive vie privée et communications électroniques (accès aux terminaux, communications non sollicitées : à vérifier pays par pays). Il doit être libre, spécifique, éclairé, prouvable et révocable en un clic. Choisissez un outil qui enregistre la date, la version du texte et la finalité.
- Informations d'urgence locale (coupure d'eau, fermeture d'école) : certaines communes les fondent sur la mission d'intérêt public plutôt que sur le consentement. La question se discute au cas par cas avec votre DPO ; dans tous les cas l'habitant doit être informé et pouvoir se désabonner (à vérifier).
- Réseau local entre voisins, signalements, comptes : documentez la base légale retenue pour chaque finalité dans le registre. Une même application peut combiner plusieurs bases.
- Mineurs : définissez l'âge minimum d'inscription et ses effets (l'âge du consentement numérique varie selon les États membres : à vérifier).
Minimisation, durées et droits des personnes
Posez-vous, module par module, la question : de quelles données avons-nous réellement besoin ? Une application de commune a rarement besoin de la date de naissance ou d'un justificatif d'identité pour envoyer une information de voirie. Plus vous collectez, plus vous devez protéger, informer et purger.
- Dressez l'inventaire : coordonnées pour les notifications, adresse ou quartier, signalements (photo, position, description), publications du réseau local, journaux de connexion, échanges avec l'assistant IA, journal d'audit.
- Fixez une durée par catégorie et faites-la configurer dans l'outil. Il n'existe pas de durée universelle : elle dépend de la finalité, des obligations d'archivage publiques et du droit national (à vérifier). Évitez « tant que le compte existe » pour les données sensibles.
- Photos et signalements : conseillez de ne pas photographier de personnes ni de plaques ; prévoyez un floutage ou une suppression par la commune.
- Droits : accès, rectification, effacement, limitation, opposition, portabilité selon les cas. Désignez qui reçoit les demandes, qui les traite et dans quel délai ; le délai légal est court (à vérifier). Demandez à l'éditeur quelles fonctions de recherche, d'export et d'effacement existent.
- Information : une politique de confidentialité claire, dans les langues de l'application, accessible avant l'inscription.
Registre, DPO et analyse d'impact
- Registre des activités de traitement (article 30) : ajoutez-y une ligne ou plusieurs lignes par finalité de l'application (alertes et information, signalements, réseau local, assistant IA…). L'éditeur doit vous aider à les remplir.
- Délégué à la protection des données (DPO) : la désignation est obligatoire pour les autorités et organismes publics (article 37). Beaucoup de communes mutualisent un DPO (intercommunale, CPAS, province, centre de gestion, prestataire) : associez-le dès le début du projet, pas à la veille de la signature.
- Analyse d'impact (AIPD/DPIA, article 35) : nécessaire quand le traitement est susceptible d'engendrer un risque élevé : surveillance à grande échelle, données sensibles, personnes vulnérables, croisement de données, usage innovant. Un module destiné aux seniors isolés, un fil local avec géolocalisation ou une IA traitant des demandes individuelles méritent d'être examinés. Les autorités nationales publient des listes de traitements concernés : consultez celle de votre pays (à vérifier).
- Violations de données : prévoyez la procédure interne et les contacts, y compris le délai de notification à l'autorité (à vérifier) et celui que l'éditeur s'engage à respecter vis-à-vis de vous.
- Sécurité du back-office : authentification forte pour les agents, rôles limités, journal d'audit. Posez la question à l'éditeur.
Hébergement, notifications push et transferts hors UE
Le lieu d'hébergement et les prestataires intervenant dans la chaîne comptent autant que le contrat. Demandez : région d'hébergement des bases de données et des sauvegardes, nom et pays de chaque sous-traitant ultérieur, personnel de support accédant aux données et depuis quels pays, conditions d'un éventuel accès ponctuel de support (consentement de la commune, durée limitée, journalisation).
- Notifications push : elles transitent par les services des fabricants de systèmes (Google pour Android, Apple pour iOS), qui peuvent traiter des données hors de l'Union. Le contenu des messages doit rester minimal (pas de donnée personnelle ni sensible dans le texte) et le point doit apparaître dans l'accord de sous-traitance et la politique de confidentialité.
- Transferts hors Espace économique européen : ils exigent un mécanisme (décision d'adéquation, clauses contractuelles types, etc.). Le cadre transatlantique de protection des données existe pour les entreprises américaines certifiées : la certification d'un prestataire et la situation juridique se vérifient au moment de signer (à vérifier).
- Suisse : la loi fédérale sur la protection des données révisée (nLPD / revDSG) s'applique depuis septembre 2023 (à vérifier). Une commune suisse doit s'assurer que son prestataire est hébergé en Suisse ou dans un pays reconnu comme offrant une protection adéquate. Pour le droit cantonal applicable aux communes, renseignez-vous auprès du préposé cantonal.
- IA : si l'application utilise un modèle de langage externe, identifiez le fournisseur, le pays et si les données personnelles sont retirées avant envoi. Voir L'IA au service des habitants : garde-fous.
Des critères RGPD à inclure dans un cahier des charges sont proposés dans Marchés publics : acheter une application citoyenne et Choisir une application communale : 15 questions.
Questions fréquentes
Une commune a-t-elle besoin du consentement pour envoyer une notification ?
Pour les notifications push, SMS et e-mails, le consentement est la base la plus sûre, notamment au regard des règles de communications électroniques. Pour l'information d'intérêt public strictement nécessaire, certaines communes retiennent la mission d'intérêt public : à valider avec votre DPO (à vérifier).
Le fournisseur peut-il utiliser les données de nos habitants pour améliorer son produit ?
Pas sans cadre strict. Comme sous-traitant, il ne traite les données que sur instruction de la commune. Toute utilisation pour ses propres fins doit être exclue ou expressément encadrée dans l'accord de sous-traitance.
Quand faut-il faire une analyse d'impact ?
Quand le traitement est susceptible d'engendrer un risque élevé pour les personnes : suivi à grande échelle, données sensibles, personnes vulnérables, géolocalisation fine, croisements de données. Consultez votre DPO et la liste de votre autorité nationale (à vérifier).
Ce guide est informatif et ne constitue pas un avis juridique. Les règles et les seuils évoluent : vérifiez-les auprès de votre service juridique, de votre délégué à la protection des données ou de l'autorité compétente.