Google Forms fonctionne bien lorsqu’une seule personne possède le formulaire. Lorsque plusieurs membres d’une équipe s’impliquent — plusieurs éditeurs, différents rôles, données de réponse sensibles — les frictions commencent à apparaître de manière spécifique et prévisible.
Ce ne sont pas des bugs. Ce sont simplement les limites de ce que Google Forms a été conçu pour gérer. Si votre équipe rencontre des problèmes de collaboration avec Google Forms, ou si vous évaluez si c’est le bon choix avant de construire quelque chose d’important dessus, les cinq limitations ci-dessous sont celles qu’il vaut la peine de comprendre.
La disponibilité des fonctionnalités dans Google Forms peut changer. Vérifiez la fonctionnalité actuelle dans la documentation officielle de Google avant de prendre des décisions basées sur cet article.
Sur cette page
1. Seulement deux niveaux de permission — rien entre les deux
Google Forms distingue deux niveaux d’accès autour d’un formulaire : Éditeurs et Répondants.
Un Répondant est toute personne ayant le lien du formulaire — elle peut le remplir et le soumettre. Un Éditeur est un collaborateur qui peut faire tout le reste — modifier les questions, supprimer les réponses, partager le formulaire avec d’autres personnes, et voir toutes les soumissions.
Il n’y a pas de rôle de collaborateur en lecture seule pour le formulaire lui-même. Il n’y a aucun moyen de laisser quelqu’un revoir ou approuver un formulaire avant sa mise en ligne sans lui donner également la possibilité de le modifier. Il n’y a pas de rôle de collaborateur qui sépare “peut voir les réponses” de “peut modifier le formulaire.”
Un exemple courant : un responsable de département doit examiner les réponses entrantes sans pouvoir les modifier ou les supprimer. Dans Google Forms, il n’y a pas de rôle pour cela — leur donner accès aux réponses signifie leur donner un accès complet en tant qu’éditeur au formulaire lui-même.
Pour les petites équipes où tout le monde a besoin du même niveau d’accès, cela convient. La limitation apparaît lorsque vous avez des rôles distincts : quelqu’un qui construit le formulaire, quelqu’un qui le révise avant sa mise en ligne, quelqu’un qui traite les réponses entrantes, et quelqu’un qui audite périodiquement ce qui s’est passé. Avec deux niveaux, vous finissez par sur-permissionner ou exclure des personnes qui ont besoin d’un accès partiel.
La solution courante consiste à partager la feuille Google liée avec des personnes spécifiques, leur donnant accès aux données de réponse sans accès en tant qu’éditeur du formulaire. Cela fonctionne, mais cela signifie gérer les permissions à deux endroits distincts — ce qui crée ses propres problèmes (voir limitation 4).
2. Les éditeurs ont un accès complet à toutes les réponses
Lorsque vous ajoutez quelqu’un en tant qu’éditeur sur un Google Form, il obtient immédiatement accès à chaque soumission que le formulaire a jamais collectée — tout cela, en entier.
Il n’y a aucun moyen de donner à un éditeur accès uniquement à un sous-ensemble de réponses. Il n’y a aucun moyen de restreindre les champs qu’ils peuvent voir dans une soumission. Il n’y a aucun moyen de laisser quelqu’un traiter de nouvelles réponses entrantes sans lui donner également l’ensemble complet des données historiques.
Cela devient une contrainte réelle dans quelques scénarios courants :
Formulaires RH où les réponses contiennent des données de rémunération, des notes de performance, ou des informations personnelles que seules certaines personnes devraient voir. Ajouter un nouveau coordinateur RH en tant qu’éditeur signifie qu’il peut voir tout ce qui a été soumis avant son arrivée.
Formulaires d’admission en soins de santé où différents membres du personnel gèrent différentes parties du processus d’admission. Les informations de santé protégées doivent être accessibles uniquement à des rôles spécifiques, mais Google Forms n’a aucun moyen de l’appliquer au niveau du champ ou de la soumission. Pour un aperçu plus large de ce que cela signifie pour les équipes de soins de santé, voir Google Forms est-il conforme à la HIPAA ?
Formulaires multi-départements où chaque département ne devrait voir que ses propres soumissions. Un exemple concret : une entreprise utilise un Google Form pour collecter des demandes de renseignements commerciaux, avec à la fois l’équipe de vente et l’équipe de support client ajoutées en tant qu’éditeurs pour que l’un ou l’autre puisse faire un suivi. Chaque éditeur sur ce formulaire — y compris le personnel de support — peut voir chaque opportunité de vente dans le pipeline, y compris les tailles de transaction, les coordonnées, et les notes internes qui ne leur étaient pas destinées. Il n’y a aucun moyen de donner au support un accès uniquement aux nouvelles demandes, ou de filtrer la vue des réponses par le département qui devrait traiter chaque soumission.
Formulaires à fort volume où le traitement des réponses est divisé entre une équipe plus large. Les processeurs individuels n’ont généralement pas besoin de l’historique complet des soumissions — juste de la file d’attente qui leur est pertinente.
Le seul contrôle disponible est de savoir s’il faut ajouter quelqu’un en tant qu’éditeur ou non. Une fois qu’ils sont éditeurs, l’accès est complet.
3. Pas de journal d’audit au niveau du formulaire
Google Forms n’a pas de registre intégré de qui a accédé à une soumission spécifique, qui a exporté des données de réponse, qui a supprimé une réponse, ou quand l’une de ces actions a eu lieu.
Les administrateurs de Google Workspace peuvent accéder aux journaux d’audit de Drive via la console d’administration — mais cela nécessite un plan Workspace entreprise, les journaux vivent au niveau de l’administration plutôt qu’au niveau du propriétaire du formulaire, et ils couvrent l’activité de Drive de manière générale plutôt que les événements d’accès spécifiques au formulaire. Pour la plupart des équipes utilisant Google Forms via des plans Workspace standards ou des comptes Google gratuits, cela n’est pas pratiquement accessible.
Cela importe de deux manières. Premièrement, si quelque chose tourne mal — une réponse disparaît, une exportation se produit alors qu’elle n’aurait pas dû, quelqu’un accède à des données qu’il n’était pas censé voir — il n’y a pas de registre pour reconstituer ce qui s’est passé ou qui en était responsable. Deuxièmement, pour les organisations ayant des exigences de conformité autour de la journalisation des accès (HIPAA, RGPD, SOC 2), l’absence de journaux d’audit accessibles est une limitation structurelle, pas quelque chose qui peut être configuré. Le principe de responsabilité du RGPD (Article 5(2)) exige que les contrôleurs puissent démontrer la conformité avec l’Article 5(1) — une exigence plus difficile à satisfaire sans enregistrements de qui a accédé aux données personnelles et quand. Pour un aperçu complet de ce que le RGPD exige des outils de formulaire, voir Conformité RGPD pour les formulaires en ligne : une checklist pratique.
4. Les permissions du Formulaire et de la Feuille sont gérées séparément
Lorsque vous liez un Google Form à une Google Sheet, les permissions sur le formulaire et les permissions sur la Feuille sont complètement indépendantes et ne se synchronisent pas automatiquement.
Ajouter quelqu’un en tant qu’éditeur de formulaire ne lui donne pas accès à la Feuille. Ajouter quelqu’un en tant que visualiseur de Feuille ne lui donne aucun accès au formulaire. Retirer quelqu’un du formulaire ne le retire pas de la Feuille.
D’après la documentation de Google : “Lorsque vous créez une nouvelle feuille de réponses, les collaborateurs du formulaire y ont automatiquement accès. Les modifications ultérieures des permissions du formulaire ne se synchroniseront pas automatiquement. Pour changer ou supprimer l’accès, mettez à jour les permissions à la fois sur le formulaire et sur la feuille liée séparément.”
En pratique, cela signifie que chaque changement de permission nécessite deux mises à jour distinctes — et il est facile d’en manquer une.
Le mode d’échec le plus courant est le roulement du personnel. Quelqu’un quitte l’équipe : son manager le retire du Google Form, considère que le processus de départ est terminé, et passe à autre chose. Trois mois plus tard, il apparaît que l’ancien employé a toujours un accès en édition à la Feuille liée — et avec elle, l’ensemble du jeu de données de réponses. Rien dans Google Forms n’a signalé l’écart, car le formulaire et la Feuille sont des systèmes indépendants aux yeux de Google.
L’inverse se produit également : un nouveau membre de l’équipe est ajouté en tant qu’éditeur de formulaire mais ne comprend pas pourquoi il ne peut pas voir les données — il a besoin d’un accès séparé à la Feuille, que personne ne lui a mentionné, et que le formulaire lui-même ne demande pas.
Pour les équipes qui utilisent à la fois le formulaire et la Feuille dans le cadre de leur flux de travail, c’est une charge de maintenance continue qui s’accumule avec le temps, en particulier sur les formulaires qui fonctionnent depuis un certain temps et ont traversé plusieurs cycles de changements d’équipe. Si vous pensez à la sécurité des données de manière plus large, 7 signes que votre constructeur de formulaires en ligne n’est pas sûr pour les données sensibles couvre à quoi ressemble ce type d’écart de permission en pratique.
5. Pas d’historique des versions pour les modifications du formulaire
Google Docs et Sheets ont tous deux un historique des révisions — vous pouvez voir chaque changement, qui l’a fait, et restaurer n’importe quelle version précédente. Google Forms ne fournit pas d’historique des révisions intégré comparable à Google Docs ou Sheets.
Si un membre de l’équipe modifie une question, change une option dans un menu déroulant, réorganise des champs, ou supprime une section, il n’y a aucun moyen intégré de voir ce qui a changé, qui l’a changé, ou à quoi ressemblait le formulaire auparavant. Revenir en arrière nécessite de reconstruire manuellement l’état précédent.
Sans historique des versions, les équipes perdent la capacité d’enquêter sur les erreurs de configuration ou de démontrer comment un formulaire a évolué au fil du temps. Cela importe le plus dans deux situations. Premièrement, lorsqu’un changement casse quelque chose dans un formulaire en direct — une question sur laquelle la logique conditionnelle dépendait est modifiée, ou une option de menu déroulant est renommée d’une manière qui ne s’aligne pas avec les données de réponse existantes. Un membre de l’équipe modifie une étiquette de champ, le formulaire cesse de s’orienter correctement, et il n’y a aucun moyen de voir à quoi il ressemblait avant ou qui a fait le changement. Deuxièmement, pour les formulaires sensibles à la conformité où le libellé exact d’une question à un moment donné peut devoir être documenté — pour des dépôts légaux, des audits, ou des examens réglementaires — et cet enregistrement n’existe tout simplement pas.
Pour les formulaires que plusieurs personnes modifient activement, l’absence d’historique des versions signifie que l’équipe n’a aucun enregistrement de l’évolution du formulaire au fil du temps.
Ce que cela signifie en pratique
Ces limitations ne rendent pas Google Forms inutilisable pour les équipes. Pour des cas d’utilisation simples — collecter des inscriptions à des événements, réaliser des enquêtes internes, recueillir des retours ponctuels — le modèle de collaboration fonctionne suffisamment bien.
La friction devient significative lorsque :
- Les données de réponse sont sensibles et l’accès doit être restreint par rôle ou type de données
- Les changements de personnel nécessitent des mises à jour de permissions fiables à la fois sur le formulaire et la Feuille
- L’équipe doit démontrer qui a accédé à quoi et quand pour des raisons de conformité
- L’édition active du formulaire par plusieurs personnes doit être suivie et potentiellement inversée
Les équipes qui rencontrent régulièrement ces scénarios finissent par gérer un ensemble de solutions de contournement — permissions de Feuille séparées, documentation manuelle des changements, dépendance aux journaux d’administration de Workspace — qui ajoutent des charges au fil du temps.
Comment PlatoForms gère ces scénarios
Pour référence, voici comment PlatoForms aborde les mêmes problèmes — pas comme une vente forcée, mais comme une comparaison concrète si vous évaluez des alternatives.
Niveaux de permission : PlatoForms a trois rôles distincts par formulaire — Éditeur de formulaire (peut modifier le formulaire), Soumetteur de formulaire (peut soumettre le formulaire), et Visualiseur de soumissions de formulaire (peut voir les données de réponse). Chaque rôle est attribué indépendamment, vous pouvez donc donner à quelqu’un un accès en visualisation aux réponses sans lui donner un accès en édition au formulaire, ou restreindre qui peut soumettre sans affecter qui peut voir les résultats. Ceux-ci peuvent être définis comme Public, Tous les membres de l’équipe, ou des individus spécifiques.
Permissions croisées de formulaire : Les administrateurs d’équipe ont une page dédiée Permissions de formulaire qui leur permet de gérer l’accès Éditeur, Soumetteur, et Visualiseur sur chaque formulaire de l’équipe à partir d’un seul endroit — utile lors des changements de personnel sans avoir besoin d’ouvrir chaque formulaire individuellement. Des membres spécifiques peuvent également se voir accorder le même accès croisé via Gérer l’accès.
Journal d’audit : Disponible sur les équipes avec le mode de conformité HIPAA activé (plans Silver et Gold). Les administrateurs d’équipe peuvent voir un journal de l’activité de partage, d’authentification, et d’accès. C’est une fonctionnalité de niveau HIPAA, non disponible sur tous les plans.
Historique des versions : PlatoForms enregistre automatiquement votre formulaire à intervalles réguliers, et enregistre également une version chaque fois que vous publiez. Vous pouvez voir toutes les versions précédentes dans le panneau Historique (accessible via ⋯ → Historique dans le constructeur de formulaire), avec des marqueurs codés par couleur indiquant si chaque version a été enregistrée automatiquement, manuellement, ou créée au moment de la publication. Toute version précédente peut être restaurée en un clic.
Si vous utilisez actuellement Google Forms et souhaitez transférer vos formulaires existants, la fonctionnalité importer depuis Google Forms gère la migration sans reconstruire à partir de zéro.
Lecture connexe : 7 signes que votre constructeur de formulaires en ligne n’est pas sûr pour les données sensibles · Conformité RGPD pour les formulaires en ligne : une checklist pratique · Google Forms est-il conforme à la HIPAA ?
