Les bases réglementaires, traitées.
nLPD suisse, RGPD, accessibilité, cookies, SEO et Core Web Vitals. Faits une seule fois, proprement, et documentés assez clairement pour que votre conseil puisse les lire sans décrocher le téléphone.
Un site défendable devant votre DPO, vos auditeurs et un régulateur — livré au même standard que le reste de la marque.
La conformité, c'est du design — avec de la paperasse.
La plupart des studios collent une bannière cookies et un modèle de politique de confidentialité à la fin et appellent ça fait. La plupart des cabinets vous envoient un mémo de 30 pages et laissent l'implémentation à votre équipe technique débordée. Estorya se place entre les deux : nous livrons la couche réglementaire comme nous livrons le reste du site — rédigée, conçue, codée, testée, documentée.
Le résultat est un site qui tient face à un contrôle sans ralentir la marque. Nous ne remplacerons pas votre conseil ; nous transformerons sa relecture en une seule passe au lieu de mois d'allers-retours sur ce que vous avez réellement livré.
Le pilier Conformité, en détail.
Chacun peut être pris seul ou combiné. La plupart des clients prennent vie privée + cookies + accessibilité ensemble, en un seul mandat audit-puis-correctif.
- 01
Vie privée — nLPD suisse + RGPD
Notices, registres et procédures qui collent à ce que le site fait vraiment — pas un modèle copié d'une autre entreprise.
Nous cartographions chaque flux de données sur le site et le back-office, écrivons une politique de confidentialité en langage clair qui correspond à la réalité, et produisons un registre des activités de traitement (RAT / ROPA) prêt à être validé par votre conseil. Là où vous opérez en transfrontalier, nous documentons le mécanisme de transfert ; là où vous collectez des données sensibles, nous ajoutons une AIPD-light pertinente.
Si vous n'avez pas de DPO, nous vous disons s'il vous en faut un, à quoi ressemble le rôle, et quels contrôles peuvent supprimer l'obligation. Le livrable est lisible par un régulateur en vingt minutes — pas un deck de 60 pages que personne n'ouvre.
- Cartographie des flux de données (site + back-office)
- Politique de confidentialité en langage clair (EN + FR)
- Registre des traitements (RAT / ROPA)
- Procédure d'accès + suppression
- Documentation des transferts transfrontaliers
2 – 4 semaines · responsable vie privée + ingénieur senior
- 02
Accessibilité — WCAG 2.2 AA
Un audit, une liste de corrections, et une déclaration d'accessibilité qu'on peut tenir.
Nous auditons le site contre WCAG 2.2 AA avec un vrai lecteur d'écran, un vrai clavier, et un outil automatique — les trois. Nous vous donnons une liste de corrections priorisées (risque légal, gain rapide, agréable-à-avoir), puis nous livrons les corrections dans le design system pour qu'elles tiennent après la prochaine refonte.
Vous repartez avec une déclaration d'accessibilité honnête sur ce qui est couvert, et un petit playbook d'auteur : ce que chaque nouvelle page ou composant doit valider avant de partir. Nous traitons ça comme un problème de qualité de design d'abord, d'exposition légale ensuite.
- Audit WCAG 2.2 AA (manuel + automatisé)
- Plan de correction priorisé
- Corrections au niveau composant dans le design system
- Déclaration publique d'accessibilité (EN + FR)
- Playbook d'auteur + QA pour les nouvelles pages
3 – 6 semaines · designer senior + ingénieur senior
- 03
Cookies + gestion du consentement
Une bannière de consentement honnête, calée sur ce que vous chargez vraiment, et stockée pour pouvoir la prouver.
Nous remplaçons la bannière générique par une couche de consentement aux couleurs de la marque, calée sur les cookies et SDK que vous chargez vraiment, et qui enregistre la preuve de consentement pour répondre à la question « qui a consenti à quoi, quand ? » des mois plus tard. La politique cookies est rédigée, pas générée, et reste synchrone avec la bannière.
Là où la loi se durcit — catégories granulaires, no-tracking-avant-consentement, comportement géo pour visiteurs CH vs. UE vs. UK — nous l'implémentons. Là où ça ne s'applique pas, nous gardons l'UX hors du chemin de la conversion.
- Bannière de consentement personnalisée + UI des préférences
- Politique cookies (EN + FR)
- Audit des scripts + SDK actuellement chargés
- Journal de consentement + stockage de la preuve
- Variante géo (CH / UE / UK / US)
1 – 3 semaines · ingénieur senior + designer
- 04
SEO de base + Core Web Vitals
L'hygiène technique que Google récompense : balisage propre, données structurées, budget de performance, pas de meta cassée.
Pas du content marketing. La couche technique en dessous — HTML sémantique, canonical et hreflang propres pour un site bilingue, schema.org là où il rapporte des rich results, sitemaps et robots cohérents avec la réalité, budgets images et fonts qui gardent Lighthouse au vert. Nous posons un baseline, corrigeons la casse, et mettons un budget en place pour que ça reste corrigé.
Sur les sites bilingues ça compte plus qu'on ne le pense — la majorité des problèmes SEO dont nous héritons sont des erreurs de hreflang et canonical livrées par le studio sans s'en rendre compte. Deux jours de travail soigné déplacent souvent l'aiguille plus qu'un trimestre de contenu.
- Audit SEO technique + liste de corrections
- Carte hreflang + canonical (EN + FR)
- Balisage schema.org là où il paye
- Reset des sitemap + robots
- Budget de performance + baseline Core Web Vitals
1 – 3 semaines · ingénieur senior · en parallèle d'un build
- 05
Sécurité de base + préparation incident
La couche ennuyeuse : HTTPS bien fait, headers de sécurité, hygiène des dépendances, plan d'incident d'une page.
Nous durcissons le déploiement : HSTS, CSP calibré sur ce que le site charge réellement, X-Frame, Referrer-Policy, runbook de rotation des secrets, cadence de mise à jour des dépendances, et un drill backup + restore pour vérifier que ça marche vraiment. Rien d'exotique — juste les contrôles qu'un auditeur Tier-2 s'attend à trouver.
Côté humain, nous laissons un plan d'incident d'une page : qui appelle qui, ce qu'on coupe, quel est le délai légal de notification sous nLPD et RGPD, où vit le runbook. La plupart des clients ne s'en serviront jamais. Ceux qui s'en servent sont très contents qu'il existe.
- Headers de sécurité (CSP, HSTS, etc.) calibrés sur votre stack
- Cadence de mise à jour des dépendances + rotation des secrets
- Drill backup + restore
- Plan de réponse à incident d'une page
- Synthèse audit-ready pour les achats
1 – 2 semaines · ingénieur senior
Quatre phases. Audit d'abord, correction unique, documentation soignée.
- Phase 01
Auditer
1 – 2 semainesNous crawlons le site et les outils support, interviewons les responsables des données, et produisons un rapport de gaps écrit. Ce qui est cassé, ce qui manque, ce qui est un risque vs. agréable-à-avoir, et comment chaque point se classe sous nLPD + RGPD + WCAG.
- Phase 02
Corriger
2 – 6 semainesNous corrigeons d'abord ce qui est à risque élevé et livrons à l'intérieur du design system existant pour que les changements survivent à la prochaine refonte. Notices, couche de consentement, corrections d'accessibilité, SEO technique et headers de sécurité atterrissent dans la même fenêtre de release.
- Phase 03
Documenter
1 – 2 semainesNous laissons une trace écrite que votre conseil et votre CTO peuvent tous deux lire : RAT, déclaration d'accessibilité, politique cookies, baseline sécurité, plan d'incident, playbook d'auteur. Langage clair, gardée dans le repo, versionnée avec le site.
- Phase 04
Maintenir
Continu (optionnel)Check-in trimestriel : on relance l'audit accessibilité, on revoit l'inventaire cookies, on rafraîchit le manifeste de dépendances, on actualise la politique de confidentialité si le traitement a changé. Une assurance peu coûteuse contre la dérive.
Ce que les clients demandent.
- Êtes-vous un cabinet d'avocats ?
- Non. Nous travaillons aux côtés de votre conseil — suisse ou européen — et produisons une documentation dans une forme qu'il peut signer. Si vous n'avez pas encore de conseil, nous vous orienterons vers des cabinets avec qui nous avons bien travaillé.
- L'accessibilité va-t-elle abîmer le design ?
- Presque toujours l'inverse. Les contraintes que WCAG impose — hiérarchie claire, vrais focus states, espacement généreux, contraste honnête — passent aussi pour du bon design auprès des utilisateurs voyants. Nous livrons l'accessibilité dans le design system, pas en surcouche.
- Et l'AI Act européen et les nouvelles révisions suisses ?
- Dans le périmètre. Nous mappons les obligations contre ce que votre produit fait vraiment, marquons quels contrôles vous avez déjà, et construisons les manquants. Là où la régulation bouge encore (l'AI Act est l'exemple évident) nous le disons explicitement et nous re-vérifions chaque trimestre.
- Pouvez-vous faire un audit ponctuel sans le build ?
- Oui — la plupart des clients commencent là. Deux semaines, prix fixe, rapport écrit. Vous pouvez gérer les corrections en interne à partir du rapport, ou revenir nous voir pour les livrer. Nous ne vous pousserons pas sur un retainer.
- Existe-t-il un retainer continu pour cela ?
- Oui, optionnel. Check-in conformité trimestriel, passe mensuelle de sanité dépendances + accessibilité, on-call pour la prochaine question régulateur. Calibré sur la surface de votre produit, pas sur un bundle d'heures.
Réservez un audit conformité.
Deux semaines, prix fixe, rapport écrit. Vous repartez avec une liste de corrections priorisée et une vue claire de votre position — que nous livrions ensuite ou non.