EZOU.EU transforme votre prototype HTML en expérience client prête à envoyer : une URL HTTPS, le niveau d’accès adapté, une expiration, et une analyse du contenu si vous la demandez. Le client clique et teste ; vous gardez la maîtrise du partage et de sa fin de vie, sans envoyer de ZIP ni ouvrir un projet d’infrastructure.
1. Choisir URL, vidéo ou archive
Utilisez une URL lorsque le client doit cliquer, tester plusieurs écrans, redimensionner ou présenter la maquette en réunion. Une vidéo est préférable pour une narration contrôlée ou un prototype instable. Une archive reste utile lorsque le client doit récupérer les sources ou conserver une copie contractuelle.
Ces formats se combinent : URL temporaire pour la revue, courte vidéo de contexte, puis archive ou dépôt après acceptation. Une visualisation de données suit exactement le même chemin qu’une maquette — c’est un dossier de fichiers statiques, et le client l’explore dans son navigateur.
2. Remplacer les vraies données
La protection d’accès ne justifie pas de publier des données inutiles. Remplacez noms, emails, commandes, métriques et documents par des valeurs synthétiques. Supprimez les commentaires, consoles de debug et exports bruts. Inspectez aussi les images : une capture peut contenir une adresse, un onglet ou une notification personnelle.
La minimisation réduit l’impact d’un lien transféré et évite de transformer une simple validation d’interface en traitement de données personnelles plus large.
3. Choisir l’accès et la durée au moment de publier
- Choisir la porte d’entrée
Situation Protection de départ Démo générique, fausses données, 24 h URL non listée et expiration Maquette avant lancement Mot de passe et expiration Comité client multi-utilisateur Domaine email autorisé Données réelles sensibles Environnement contractuellement approuvé Dans EZOU.EU, ces deux décisions se prennent sur le même écran que le dépôt des fichiers — il n’y a pas d’étape « sécuriser plus tard », celle qu’on oublie.
Une revue client type : adresse lisible pour l’email, mot de passe pour la porte d’entrée, purge automatique au bout de sept jours. - Fixer l’expiration avant l’envoi
La durée suit le rendez-vous. Pour un test le lendemain, 24 heures. Pour une revue, sept jours. Trente jours pour un cycle plus long. Ce sont des repères opérationnels, pas des durées juridiques.
Ajoutez la date absolue dans l’email. Un prototype orphelin après la mission est un risque, pas un service.
- Tester comme le client
Une URL aléatoire constitue un secret de possession : quiconque connaît le lien peut entrer. Ne l’appelez pas authentifiée. Un mot de passe ajoute une barrière partagée. La restriction par domaine email vérifie une boîte appartenant au domaine annoncé ; elle n’applique pas toutes les politiques d’un SSO.
- La page d’accès ne révèle pas le contenu protégé.
- Toutes les images et polices se chargent.
- Aucun bouton ne pointe vers
localhost. - Aucun formulaire de démonstration n’envoie de données réelles.
- Le contenu non public porte
noindex. - Lien et mot de passe passent par des canaux séparés si le risque le demande.
- La date de révocation est connue et annoncée.
Ce test doit viser le dossier effectivement publié, pas seulement la version ouverte dans l’éditeur. Le client, lui, ouvrira souvent le lien depuis un téléphone.
4. Utiliser un email client explicite
Adaptez ce modèle :
Objet : Prototype interactif — revue avant vendredi
Bonjour,
Voici le prototype : [URL]
Accès valable jusqu’au [date et heure, fuseau].
Le mot de passe vous est envoyé séparément.
Merci de concentrer la revue sur le parcours et la hiérarchie.
Les contenus et données sont fictifs.
Vous pouvez centraliser vos retours dans [canal].
Points à valider :
1. compréhension de l’écran ;
2. ordre des étapes ;
3. terminologie ;
4. erreurs bloquantes ;
5. décision finale.
Évitez « Qu’en pensez-vous ? », trop vague. Une demande limitée à trois ou cinq décisions accélère la revue.
5. Savoir si le lien a été ouvert — sans traquer le client
Un compteur de pages rendues suffit à relancer au bon moment. EZOU.EU s’arrête là volontairement : aucun visiteur n’est identifié.
6. Fermer proprement la mission
À la fin, exportez les retours nécessaires, révoquez l’accès et supprimez l’artefact. Conservez uniquement les éléments imposés par le contrat ou votre processus qualité.
Checklist finale : données synthétiques, scan terminé, accès testé sans session, expiration annoncée, feedback cadré, propriétaire nommé et attestation archivée.
Pour votre prochaine revue, publiez le dossier dans EZOU.EU, choisissez l’accès et envoyez l’URL : le parcours est fait pour être plus simple que l’envoi d’une archive, et plus maîtrisé qu’un hébergement public.
Références utiles
Questions fréquentes
Peut-on envoyer directement un fichier HTML par email au client ?
Techniquement oui, mais les clients mail peuvent le bloquer et les assets se perdre. Une URL HTTPS est plus fiable pour consulter ; une archive convient mieux au transfert des sources.
Un accord de confidentialité est-il toujours nécessaire pour une maquette ?
Cela dépend du projet et de la relation contractuelle. La protection technique complète le cadre juridique, mais ne le remplace pas.
Faut-il choisir un mot de passe ou une restriction par domaine email ?
Le mot de passe convient à un petit groupe. Le domaine email évite un secret commun et convient à plusieurs lecteurs d’une organisation, sans remplacer une liste nominative ou un SSO.
Comment limiter l’indexation d’un prototype client ?
Servez un en-tête X-Robots-Tag noindex, nofollow sur le contenu non public et utilisez une authentification lorsque nécessaire. Noindex limite la visibilité ; ce n’est pas un contrôle d’accès.
Peut-on savoir si le client a consulté le prototype ?
EZOU.EU compte les pages rendues, sans identifier le visiteur : ni cookie de mesure, ni adresse IP conservée, ni empreinte. Vous savez donc qu’un lien a été ouvert, pas par qui.




