Comment fonctionne le pré-remplissage en pratique
Le principe est simple. La plateforme alumni connaît déjà beaucoup de données sur l'alumni qu'elle sollicite : nom, prénom, promo, option, parcours scolarité, parfois la situation déclarée à la dernière mise à jour de profil. Plutôt que de demander à l'alumni de retaper ces informations, on les pousse dans le formulaire au moment du chargement.
Techniquement, deux mécaniques coexistent. La première est l'URL paramétrée : le lien envoyé à l'alumni contient un identifiant unique (token) que la plateforme utilise pour récupérer le profil et pré-charger les champs. C'est ce que fait Google Forms quand il est utilisé sérieusement, mais à condition de générer manuellement les liens et les paramètres pour chaque alumni — ce qui n'est pas tenable au-delà de 50 profils.
La seconde est l'authentification : l'alumni se connecte à son espace, le formulaire s'ouvre déjà rempli avec les données du profil. Plus robuste, plus respectueux RGPD, mais demande que l'alumni ait un compte actif. Sur les plateformes alumni modernes comme Terrilink Enquêtes, les deux mécaniques cohabitent : token signé par défaut, authentification optionnelle pour les alumni qui veulent contrôler.
Le résultat : l'alumni clique sur le lien depuis son email ou son SMS, le formulaire s'ouvre, son nom est déjà inscrit, sa promo aussi, son option aussi. Il valide ou corrige, complète les questions vraiment nouvelles, et clique "envoyer". Temps total : 2 à 3 minutes au lieu de 8 à 12.
Données pré-remplissables vs données à recueillir
Toutes les données ne se pré-remplissent pas. Trois familles à distinguer.
Données structurelles (toujours pré-remplissables) : nom, prénom, promo de diplomation, type de diplôme, option/majeure, double-diplôme, mention. Ces données ne changent pas — elles peuvent être pré-remplies en lecture seule, l'alumni n'a même pas à valider.
Données déclaratives anciennes (pré-remplissables avec validation) : poste actuel, employeur, ville, statut. Ces données changent dans le temps. On les pré-remplit avec la dernière valeur connue, et on demande explicitement à l'alumni de "valider ou mettre à jour". L'erreur classique : pré-remplir sans demander de confirmation, et obtenir des données obsolètes — voir section suivante.
Données nouvelles (jamais pré-remplissables) : salaire actuel, satisfaction de la formation, opinion sur l'employeur, projet professionnel à 2-3 ans. Ces données sont l'objet même de la campagne. Elles doivent être recueillies à neuf à chaque vague, sans hypothèse.
Sur une enquête CGE 6 mois typique, on observe que 40 à 50 % des champs sont pré-remplissables (catégories 1 et 2), 50 à 60 % doivent être recueillis à neuf. C'est ce ratio qui fait passer le formulaire de 10 minutes à 3 minutes — pas une suppression brutale de questions.
Impact mesuré : durée moyenne de réponse, taux de complétude
Sur les campagnes que nous suivons, voici les ordres de grandeur observés en régime stable.
- Durée moyenne de complétion : passe de 9-12 minutes (sans pré-remplissage) à 2-3 minutes (avec pré-remplissage des catégories 1 et 2).
- Taux d'abandon en cours de formulaire : passe de 25-30 % à 5-10 %. Les abandons en cours sont massivement liés à la friction perçue, pas au contenu.
- Taux de complétude global de la promo : passe de 40-50 % à 60-70 %. C'est l'effet net, toutes choses égales par ailleurs.
- Qualité des données : un alumni qui retape son nom a 1 à 2 % de risque de typo. Pré-remplir élimine cette source d'erreur, importante pour les croisements avec d'autres bases (CCN, INSEE).
Pour une promo de 400 alumni, passer de 45 % à 65 % de taux de réponse, c'est 80 réponses supplémentaires. Sur le rapport CGE, ces 80 réponses font la différence entre un dossier solide et un dossier qui passe à peine. Pour les comparaisons par type d'école, voir notre article taux de réponse enquête CGE par type d'école.
Le risque de pré-remplir trop : alumni qui valident sans vérifier
Le pré-remplissage a un effet pervers connu : l'alumni valide sans vérifier. Si le formulaire affiche déjà "Poste actuel : Consultant chez X (mis à jour en 2024)" et que l'alumni a changé de poste depuis 4 mois, il est tenté de cliquer "Valider" sans corriger.
Le résultat : des données périmées qui se figent dans le rapport CGE. Ce sont les écoles qui pré-remplissent agressivement, sans incitation explicite à mettre à jour, qui voient leurs salaires médians stagner d'année en année (les vieux salaires se renouvellent passivement) ou leurs taux de CDI gonfler artificiellement.
Trois précautions concrètes. D'abord, marquer visuellement les champs pré-remplis ("D'après nos données...") avec un bouton "Confirmer ou modifier". L'alumni doit cliquer activement, pas juste laisser passer. Deuxièmement, poser une question explicite sur la fraîcheur : "Cette information est-elle à jour ? Oui / Non, je mets à jour". Troisièmement, recueillir certaines données toujours à neuf : salaire actuel, satisfaction. Pas de pré-remplissage là-dessus, peu importe les pertes de friction.
En sortie : un formulaire qui passe à 3 minutes pour les alumni "stables" et 4-5 minutes pour ceux qui ont changé de situation, mais avec une fraîcheur de données préservée.
RGPD : quelles bases légales pour pré-remplir ?
Pré-remplir des données personnelles dans un formulaire que l'alumni n'a pas explicitement initié, c'est traiter des données. Donc, base légale obligatoire.
Pour une enquête CGE, deux bases légales coexistent en pratique. La base "obligation légale ou mission d'intérêt public" est mobilisée par certaines écoles publiques pour le rapport HCERES / CGE — la production de statistiques d'insertion étant une obligation associée à l'accréditation. La base "intérêt légitime" est utilisée par les écoles privées : le suivi de l'insertion des diplômés est un intérêt légitime de l'établissement, à condition que l'alumni puisse s'y opposer.
Le consentement (article 6.1.a RGPD) n'est en général pas la bonne base, car il oblige à recueillir un consentement actif avant le pré-remplissage, ce qui annule l'effet "gain de friction".
Quelle que soit la base, trois exigences à respecter. Premièrement, information claire : l'alumni doit savoir, avant le formulaire, que ses données personnelles sont déjà connues de l'école et seront utilisées pour le pré-remplissage. Deuxièmement, droit d'opposition mentionné explicitement dans le formulaire et dans la politique de confidentialité dédiée à la campagne. Troisièmement, minimisation : ne pré-remplir que ce qui est strictement utile — pas le numéro de sécurité sociale, pas la date de naissance complète si la promo suffit.
Pour cadrer ça avec le DPO de l'école, voir notre guide RGPD plateforme alumni.
Implémentation : ce que demande un logiciel d'enquête CGE pour le faire
Pour pré-remplir proprement, le logiciel doit savoir faire trois choses. D'abord recevoir une base alumni par CSV ou API, avec un identifiant stable par alumni. Ensuite, générer des liens uniques signés (typiquement des JWT ou des tokens à durée limitée), pour qu'un lien envoyé à un alumni ne puisse pas être réutilisé par quelqu'un d'autre. Enfin, pré-charger les champs depuis le profil et les rendre éditables ou en lecture seule selon la catégorie de donnée.
Du côté Terrilink, ces trois fonctions sont natives sur la page Enquêtes CGE / CTI. La base alumni vit dans le SaaS toute l'année, alimentée par les programmes mentorat, les événements, les cotisations. Au moment de la campagne CGE, elle alimente le pré-remplissage automatiquement, sans aucun export-import. Pour démarrer, le plus rapide est de réserver une démo.