Puis-je collecter des adresses IP ? Ce que votre formulaire enregistre en silence
En général oui — une adresse IP est une donnée personnelle, pas une donnée interdite. La question difficile porte sur tout le reste : agent utilisateur, horodatages, référent, mesures de temps, EXIF des photos, en-têtes des courriels de notification, journaux d'erreurs et requêtes tierces côté répondant. Un inventaire champ par champ, le statut juridique de chacun sous la nLPD et le RGPD, des durées de conservation défendables, et une déclaration claire de ce que Schweizerform enregistre et n'enregistre pas.
« Puis-je collecter des adresses IP ? » est presque toujours la mauvaise première question. La réponse est généralement oui, et c'est le point le moins intéressant du sujet — car l'adresse IP est la seule métadonnée dont chacun sait qu'il la collecte. Ce qui coule une promesse d'anonymat, c'est tout le reste : l'agent utilisateur, l'horodatage à la milliseconde, le référent qui révèle la page interne d'origine, les mesures de temps, les coordonnées GPS dans la photo jointe, les en-têtes du courriel de notification, et les six requêtes vers des tiers que la page du formulaire émet avant que quiconque ait tapé un mot.
En bref
Oui, vous pouvez collecter une adresse IP — c'est une donnée personnelle au sens de la nLPD et du RGPD, pas une donnée interdite. Il vous faut une finalité, une base légale, de la transparence et une durée de conservation cohérente avec la finalité. La sécurité et la lutte contre les abus sont les justifications solides ; « pour les statistiques » ne l'est généralement pas, un signal plus grossier suffisant. Les problèmes sont ailleurs. La plupart des plateformes enregistrent par défaut une dizaine d'autres éléments, presque aucune ne publie la liste, et c'est l'accumulation qui transforme un canal « anonyme » en canal pseudonyme que votre propre informatique peut résoudre. Cet article donne l'inventaire, le statut juridique de chaque élément, des durées défendables, un audit de dix minutes à mener sur votre formulaire — et, à la fin, champ par champ, ce que Schweizerform enregistre, y compris les parties moins privées que le reste du produit.
L'inventaire : tout ce qu'un formulaire peut capter en plus des réponses
C'est la liste à parcourir avec votre plateforme, pas un acte d'accusation. Chaque fournisseur collecte un sous-ensemble différent ; l'essentiel est de pouvoir dire lequel vous concerne.
| Signal | D'où il vient | Ce qu'il peut révéler |
|---|---|---|
| Adresse IP | Toute requête HTTP — le serveur la voit, qu'il la conserve ou non | Localisation approximative, employeur ou fournisseur d'accès, et un lien entre plusieurs envois issus du même réseau |
| Agent utilisateur et données d'appareil | En-têtes de requête ; parfois taille d'écran et plateforme via JavaScript | Une empreinte étonnamment étroite — une combinaison inhabituelle version de navigateur, système et résolution est presque unique dans un petit groupe |
| Horodatages | Horloge du serveur, à la précision conservée par le fournisseur | Recoupement avec les badgeuses, les plannings, les agendas. Un envoi à 03h12 un dimanche réduit fortement le cercle |
| Référent et paramètres UTM | La page d'où venait la personne | Qu'elle venait d'une page intranet précise, d'un lien privé ou d'une campagne ciblée |
| Télémétrie de temps et d'interaction | JavaScript sur la page : temps par champ, hésitations, corrections, parfois les frappes | L'hésitation sur une question sensible. À l'extrême (rejeu de session), les réponses tapées puis effacées |
| Cookies et stockage local | Posés par la page du formulaire ou par des tiers intégrés | Visites répétées, recoupement entre formulaires et — avec des traceurs tiers — une activité bien au-delà de votre formulaire |
| Métadonnées de fichiers (EXIF) | Photos et documents joints par la personne | Coordonnées GPS, heure de prise de vue, numéro d'appareil ; dans les fichiers bureautiques, l'auteur et l'historique |
| En-têtes du courriel de notification | Le message envoyé par votre plateforme à l'arrivée d'une réponse | Les serveurs impliqués — et, si les réponses figurent dans le corps, une copie non chiffrée permanente dans plusieurs boîtes |
| Supervision d'erreurs et de performance | Outils tiers de crash/APM sur la page du formulaire | URL, fragments de charge utile, parfois des valeurs de champ dans les contextes d'erreur |
| Requêtes CDN, polices et CAPTCHA | Tout ce que la page charge depuis un autre hôte | L'adresse IP et l'agent utilisateur de la personne sont communiqués à cet hôte, que vous appeliez cela « partage » ou non |
| Identifiants de compte | Un formulaire derrière une authentification d'entreprise ou un SSO | Tout. Si la personne est authentifiée, le reste de la liste n'a plus d'importance |
Le problème de l'accumulation
Aucun élément de cette liste n'identifie seul une personne dans une grande population. Quatre d'entre eux ensemble identifient la plupart des gens dans une organisation de deux cents personnes. C'est pourquoi « nous ne stockons pas les noms » n'est pas une affirmation d'anonymat, et pourquoi la vraie question n'est pas « collectons-nous l'IP » mais « quel est le plus petit groupe dont cet envoi peut provenir ».
Une adresse IP est-elle une donnée personnelle ?
Selon l'art. 5 let. a nLPD, sont des données personnelles toutes les informations concernant une personne physique identifiée ou identifiable. Une adresse IP concerne une personne dès lors qu'existent des moyens dont l'emploi est raisonnablement envisageable — et dans l'UE, la Cour de justice a tranché la question équivalente dans Breyer (C-582/14, 2016) : une adresse IP dynamique est une donnée personnelle pour l'exploitant d'un site qui dispose de moyens juridiques d'obtenir l'identité auprès du fournisseur. Traitez une IP comme une donnée personnelle. La position inverse est perdante et ne vous rapporte rien.
Ce qui a bougé récemment concerne les données pseudonymisées. En septembre 2025, la Cour de justice a jugé dans EDPS c. CRU (C-413/23 P) que l'identifiabilité s'apprécie de manière relative : des données suffisamment pseudonymisées peuvent être des données personnelles pour le responsable initial et ne pas l'être pour un destinataire qui ne peut raisonnablement réidentifier personne, compte tenu des facteurs techniques, organisationnels et juridiques.
Cela concerne directement les plateformes de formulaires, car c'est la différence entre deux conceptions qui prétendent toutes deux « ne pas stocker d'IP » :
- Un hachage de l'IP avec un algorithme fixe et connu. Réversible par force brute — l'espace IPv4 s'énumère en quelques secondes. Ce n'est pas de la pseudonymisation mais de l'obscurcissement, et cela doit être traité comme une IP.
- Un hachage à clé avec un secret que l'attaquant n'a pas, salé par formulaire. Non réversible sans le secret côté serveur et non recoupable entre formulaires, puisque la même adresse donne un condensat différent par formulaire. C'est réellement un autre objet — et l'approche relative est ce qui permet de le dire.
- Aucun identifiant du tout. Rien à inverser, rien à communiquer, rien à conserver. Toujours la position la plus forte — et celle à retenir chaque fois que la finalité peut être atteinte autrement.
La distinction de fond — anonyme ou pseudonyme, et pourquoi la plupart des formulaires « anonymes » ne sont ni l'un ni l'autre — figure dans formulaires anonymes ou pseudonymes.
Quand la collecte est défendable — et pour combien de temps
Le droit suisse n'exige pas le consentement pour la plupart des traitements par un privé ; il exige licéité, proportionnalité, reconnaissabilité et bonne foi (art. 6 nLPD), un intérêt prépondérant étant disponible à l'art. 31 lorsqu'un motif justificatif est nécessaire. Côté RGPD, la voie habituelle pour les mêmes faits est l'intérêt légitime de l'art. 6 par. 1 let. f avec une mise en balance documentée. Dans les deux systèmes, la question qui tranche est de savoir si un moyen moins intrusif atteindrait la même finalité. Les métadonnées échouent à ce test bien plus souvent que les champs du formulaire.
| Finalité | Défendable ? | Conservation raisonnable |
|---|---|---|
| Journaux de sécurité — détection d'intrusion, analyse d'incident | Oui, c'est le cas le plus solide | De quelques jours à quelques mois, puis suppression automatique. Pas « pour toujours, au cas où » |
| Limitation de débit et blocage du trafic abusif | Oui, mais sans nécessiter une conservation au-delà de la fenêtre | La durée de la fenêtre ; des blocages avec date d'expiration |
| Prévention des doublons | Oui avec une valeur dérivée, discutable avec l'adresse elle-même | Aussi longtemps que l'envoi, pas plus ; supprimer les deux ensemble |
| Prévention de la fraude sur un formulaire avec paiement | En général oui, avec le raisonnement documenté | Aligner sur le délai de litige ou de rétrofacturation, puis supprimer |
| « Analytique » — d'où viennent les réponses | Rarement — un pays ou un compteur grossier y suffit sans l'adresse | Ne pas stocker l'adresse du tout ; stocker la valeur dérivée |
| Prouver plus tard qui a envoyé | Seulement en cas de besoin probatoire réel — et alors, le dire à l'avance | Déterminée par l'obligation sous-jacente, pas par le confort |
| Sur un formulaire qui promet l'anonymat | Non. La finalité contredit la promesse | Sans objet — ne pas collecter |
Quel que soit votre choix, trois obligations en découlent, et ce sont celles que l'on contrôle : les métadonnées figurent au registre des activités de traitement, leurs catégories dans la déclaration de confidentialité au sens de l'art. 19 nLPD (destinataires et pays compris), et la règle de conservation doit exister par écrit et s'exécuter réellement. Voir durée de conservation des données de formulaires et la checklist nLPD pour formulaires et sondages.
La couche cookies et traceurs relève d'une autre règle
La Suisse règle les cookies dans le droit des télécommunications, non dans la loi sur la protection des données. L'art. 45c let. b LTC autorise le traitement sur l'appareil lorsque l'utilisateur est informé du traitement et de sa finalité et rendu attentif à la possibilité de le refuser — un modèle information plus opposition, non le modèle européen du consentement préalable. Le PFPDT a publié un guide sur les traitements au moyen de cookies et de technologies similaires (version 1.1 du 6 octobre 2025) qui attend que la possibilité de refus soit visible et exerçable en quelques clics plutôt qu'enfouie. Si des données personnelles sont traitées, la nLPD s'ajoute ; et si vos répondants sont dans l'UE, le standard de consentement ePrivacy s'applique à eux quel que soit votre siège.
Pour une page de formulaire, la règle pratique est bien plus simple que le droit : pas de traceur non essentiel dessus. Un formulaire qui ne charge ni analytique, ni gestionnaire de balises, ni polices externes, ni CAPTCHA tiers n'a besoin d'aucune bannière, ne communique l'IP du répondant à personne, et convertit mieux parce qu'aucune fenêtre ne s'interpose avant la première question. La publicité et la mesure ont leur place sur vos pages marketing, où l'arbitrage est une vraie décision d'entreprise et non un accident.
Les quatre que vous ne saviez pas collecter
1. Les données EXIF des photos téléversées
Une photo prise au téléphone porte souvent des coordonnées GPS, l'heure de la prise de vue et l'identité de l'appareil. Qui photographie un défaut chez lui, une blessure ou un document sur la table de la cuisine joint son adresse privée à un signalement qu'il croyait anonyme. Supprimez les métadonnées au téléversement quand c'est possible ; sinon, écrivez-le en une phrase à côté du champ. Sur le chemin de téléversement, voir le guide complet des téléversements sécurisés.
2. Le courriel de notification
Si votre plateforme vous envoie le contenu de la réponse par courriel, vous avez créé des copies non chiffrées permanentes dans chaque boîte de la liste de diffusion, sur chaque téléphone synchronisé et dans chaque sauvegarde — plus une trace de messagerie avec ses propres en-têtes et sa propre conservation. La correction tient à un réglage : notifier qu'une réponse est arrivée, ne jamais inclure le contenu.
3. Supervision d'erreurs et rejeu de session
Les outils de rapport de plantage et de rejeu de session sont installés pour améliorer le produit et sont généralement invisibles pour la personne qui rédige la déclaration de confidentialité. Les deux peuvent capter des valeurs de champ — le rejeu par construction, la supervision d'erreurs par accident, dans les charges utiles et les contextes d'erreur. Sur un formulaire portant sur la santé, les RH ou le juridique, un script de rejeu tiers est une communication de données sensibles à un sous-traitant que personne n'a documenté.
4. Tout ce que la page charge depuis un autre hôte
Une police web, une bibliothèque d'icônes, un CDN, un CAPTCHA : chacun reçoit l'adresse IP et l'agent utilisateur du répondant comme condition de la livraison du fichier. C'est une communication — et si l'hôte est à l'étranger, une communication transfrontière dont la base au sens des art. 16/17 doit être documentée. C'est aussi le point le plus facile à vérifier de cette page : voir l'audit ci-dessous et quels outils de formulaires sont hébergés en Suisse.
Ce que Schweizerform enregistre — champ par champ
Nous le publions parce que nous le demandons aux autres fournisseurs. Chez Schweizerform, un envoi est une ligne en base de données plus un bloc chiffré dans un stockage objet suisse. Voici la ligne entière :
| Enregistré | De quoi il s'agit | Pourquoi |
|---|---|---|
| Identifiant d'envoi, identifiant de formulaire, chemin de stockage | Identifiants de l'enregistrement et de son texte chiffré | Nécessaires pour lire et supprimer l'envoi |
| Clé encapsulée et IV | La clé AES de l'envoi, chiffrée sous la clé publique du formulaire | Seule la clé privée du propriétaire la déchiffre — le serveur ne le peut pas |
| Date d'arrivée, date de lecture | Quand il est arrivé et quand le propriétaire l'a déchiffré pour la première fois | Tri de la boîte de réception et indicateur « non lu » |
| Taille en octets | Total des octets chiffrés stockés | Comptabilisation du quota de stockage |
| Durée, nombre de réponses, nombre de questions | Trois entiers grossiers : temps entre l'ouverture et l'envoi, questions renseignées, questions existantes | Analyse de complétion. Bornée, sans identité, jamais par question et par personne |
| Langue d'envoi | Laquelle des quatre langues était affichée | Restitution multilingue. Validée contre la liste supportée, sinon vide |
| Empreinte d'envoi — uniquement si vous activez « une fois par réseau » | Un HMAC à clé de (identifiant de formulaire + IP) sous un secret côté serveur | Prévention des doublons. Salée par formulaire donc non recoupable, non réversible en adresse, et supprimée avec l'envoi |
| Marqueur de lot perdu | Vide, sauf si le compte a subi une réinitialisation de clé du coffre sans code de récupération | Mise en quarantaine plutôt que suppression — le texte chiffré est conservé pour être récupéré ou purgé délibérément |
| Étiquettes que vous appliquez | Courts libellés ajoutés par le propriétaire après déchiffrement, stockés en clair | Filtrage et tri dans la boîte de réception sans tout déchiffrer d'abord. Rédigées par vous, jamais par le répondant |
Et voici ce qui n'y figure pas : aucune adresse IP, aucun agent utilisateur, aucune donnée d'appareil ou de navigateur, aucun référent, aucune géolocalisation, aucun identifiant de cookie ou de visiteur, aucun temps de réponse par question et aucun compte — les répondants n'en ont jamais besoin. Une page de formulaire publique incrémente un compteur de vues quotidien (et un compteur distinct pour les scans QR) ; elle ne crée pas d'enregistrement de visite. Les statistiques par question sont des compteurs agrégés plats : le client indique quelles questions ont été renseignées, le serveur incrémente puis jette le rapport.
Les parties moins privées, dites clairement
Notre site marketing — les pages que vous lisez, pas les pages de formulaire — utilise une analytique interne qui stocke une empreinte de navigateur grossière, l'agent utilisateur brut et un pays dérivé de votre IP via une base MaxMind GeoLite2 locale ; l'IP elle-même n'est jamais conservée et aucun service d'analytique externe n'est contacté. En exploitation, les enregistrements de limitation de débit contiennent des IP brutes le temps de leur fenêtre puis sont purgés, et les blocages d'IP conservent une adresse le temps du blocage — dans les deux cas contre les abus. Le journal d'audit enregistre IP et agent utilisateur pour les actions des titulaires de compte (connexions, modifications de formulaire, consultation ou suppression d'un envoi), car un journal d'audit incapable de dire d'où vient une action n'en est pas un. Rien de tout cela ne concerne les répondants à vos formulaires. Si un fournisseur ne peut pas vous écrire ce paragraphe sur lui-même, c'est précisément le constat.
Le raisonnement derrière l'empreinte « une fois par réseau » — pourquoi un sel par formulaire et un poivre serveur constituent les trois propriétés qui rendent un identifiant dérivé défendable, et comment les autres mécanismes anti-doublons se comparent en coût d'anonymat — figure dans prévenir le spam, les bots et les doublons sans casser l'anonymat.
Auditez votre propre formulaire en dix minutes
Ouvrez le formulaire en production avec l'inspecteur réseau
Outils de développement, onglet Réseau, rechargez. Chaque hôte distinct de cette liste reçoit l'adresse IP de votre répondant. Notez-les ; tout ce que vous ne pouvez pas expliquer est soit supprimable, soit une communication à déclarer.
Envoyez une réponse de test et regardez ce qui a été stocké
Exportez-la ou ouvrez l'enregistrement via l'API. C'est dans l'export qu'apparaissent les colonnes de métadonnées cachées — IP, agent utilisateur, géolocalisation, appareil, durées. Si l'export contient des colonnes absentes de votre déclaration, vous tenez l'écart.
Vérifiez les cookies avant et après
Onglet Application, Cookies et stockage local, avant le chargement et après l'envoi. Tout ce qui est posé par un hôte autre que le vôtre est un traceur tiers sur une page de formulaire et n'a rien à y faire.
Téléversez une photo de téléphone et relisez ses métadonnées
N'importe quel lecteur EXIF fait l'affaire. Si les coordonnées survivent au trajet, supprimez les métadonnées au téléversement ou avertissez sur le champ.
Lisez un courriel de notification comme un document
Contient-il des réponses ? Alors ces réponses vivent désormais dans chaque boîte de la liste. Coupez le contenu, gardez l'alerte.
Posez deux questions écrites au fournisseur
« Quelles métadonnées conservez-vous par envoi, et combien de temps ? » et « Quels sous-traitants les reçoivent ? » Conservez la réponse datée — c'est ce qu'il faudra devant un contrôleur, et le délai de réponse est déjà une information.
Écrivez la règle de conservation et faites-la tourner
Par catégorie : journaux de sécurité, enregistrements de limitation, envois, exports, sauvegardes. Une règle que personne n'exécute est pire que pas de règle, car elle documente une intention que vous ne tenez manifestement pas.
Personne n'a jamais décidé de collecter les métadonnées. C'est précisément le problème — une décision non prise reste une décision, et c'est celle qu'on vous demandera de défendre.
L'essentiel
Pouvez-vous collecter des adresses IP ? Généralement oui — avec une finalité, une base légale, une ligne dans votre déclaration de confidentialité et une durée de conservation qui s'achève. Ce qu'il ne faut pas faire : les collecter par défaut, les garder indéfiniment et décrire en même temps le formulaire comme anonyme. Ces trois habitudes transforment un détail technique en constat de protection des données.
Le bon modèle mental : chaque formulaire a deux charges utiles — les réponses, que vous avez conçues, et les métadonnées, arrivées toutes seules. Vous maîtrisez la première par la liste des champs et la seconde par la plateforme choisie et les réglages que vous n'avez pas touchés. Allez regarder la seconde : dix minutes suffisent, et presque tous ceux qui le font trouvent au moins une chose qu'ils n'auraient pas acceptée.
Schweizerform enregistre les champs listés ci-dessus et rien d'autre : réponses chiffrées dans le navigateur du répondant, pas d'IP, pas d'agent utilisateur, pas de cookies sur la page du formulaire, aucune requête tierce, et des envois chiffrés stockés en Suisse dans toutes les offres, gratuite comprise. La description technique complète est sur notre page sécurité, et le guide pratique est créer un formulaire en ligne sûr.
Avertissement : cet article est une information générale et un contenu marketing, non un conseil juridique. Les renvois à la nLPD (art. 5 let. a, 6, 16, 17, 19, 31), au RGPD (art. 6 par. 1 let. f), à l'art. 45c LTC, au guide du PFPDT sur les cookies et technologies similaires (v. 1.1 du 6 octobre 2025), à la CJUE Breyer (C-582/14) et à la CJUE EDPS c. CRU (C-413/23 P, 4 septembre 2025) sont des résumés simplifiés d'un état vérifié en juillet 2026 ; le droit et son interprétation évoluent. Les affirmations sur Schweizerform décrivent le produit à cette date et peuvent changer — la page sécurité fait foi. Le comportement des produits tiers varie selon le fournisseur et l'offre ; vérifiez-le vous-même avec l'audit ci-dessus.