Comment nous avons audite chaque affirmation de notre site (et ce que nous avons trouve)

Le point de depart

OmniWatchGuard a grandi rapidement en l'espace de quelques mois — nouvelles fonctionnalites, nouvelles pages, nouveau contenu a chaque sprint. A un moment donne, je me suis rendu compte que je ne savais plus avec certitude, sans verifier le code, quelles affirmations sur le site etaient vraies et lesquelles dataient encore de la phase de planification.

Ce n'etait pas une decision deliberee de mentir. C'est le genre d'ecart qui apparait naturellement dans un produit gere par un seul fondateur : vous ecrivez le texte pour une fonctionnalite avant de la construire, vous la mettez sur la roadmap, puis, dans la precipitation de lancer d'autres choses, le texte reste inchange pendant des mois.

Le processus : comment nous avons trouve les ecarts

Nous ne sommes pas partis d'une liste de soupcons. Nous sommes partis d'une question simple :chaque fichier qui genere du contenu public — pages, composants FAQ, schema JSON-LD, calculateur de prix — correspond-il a ce qui existe reellement dans le code ?

1. Nous avons repertorie tous les fichiers qui produisent du contenu visible pour l'utilisateur ou les moteurs de recherche : FAQ.astro, FAQSchema.astro, FAQEnterprise.astro, PricingSchema.astro, Comparison.astro, Calculator.astro, SoftwareAppSchema.astro, AggregateRatingSchema.astro, privacy.astro
2. Pour chaque affirmation de fonctionnalite (« prend en charge X », « surveille Y »), nous avons cherche l'implementation reelle dans le backend/crawler
3. Nous avons classe chaque affirmation en trois categories : vraie (implementee et testee), partiellement vraie (implementee mais avec des limitations non mentionnees), fausse (uniquement sur la roadmap ou jamais construite)
4. Pour chaque affirmation fausse ou partielle, nous avons choisi l'une de deux actions : soit corriger le texte pour refleter la realite, soit construire la fonctionnalite pour qu'elle devienne vraie

Ce que nous avons trouve

Notes et temoignages codes en dur

AggregateRatingSchema.astro et Testimonials.astro avaient une note fixe de 4,9, un nombre fixe de « 200+ avis » et « 500+ entreprises », ainsi que des noms et citations de temoignages ecrits directement dans le code — ces clients n'existaient pas. Nous avons tout remplace par des donnees reelles, calculees a partir de la table reviews de la base de donnees : note moyenne et nombre d'avis reels, la section temoignages se masque d'elle-meme s'il n'existe encore aucun avis reel. Le CTA « laisser un avis » reste visible en permanence.

Fonctionnalites sur la roadmap presentees comme actives

La surveillance de pages avec connexion, le RBAC (roles et permissions) et le SSO apparaissaient dans la FAQ et le tableau comparatif comme des fonctionnalites disponibles. Elles ne l'etaient pas. Nous avons corrige les six fichiers concernes (FAQ, FAQSchema, PricingSchema, Comparison, Calculator, SoftwareAppSchema) pour indiquer clairement « Roadmap 2026 » pour RBAC/SSO, et avons completement supprime l'affirmation concernant des applications iOS/Android qui n'existaient pas et n'etaient pas prevues.

Bug d'affichage qui masquait un vrai probleme

Le composant Comparison.astro de la page d'accueil avait un bug de rendu qui affichait une coche verte (✓) pour n'importe quelle fonctionnalite, independamment des donnees reelles sous-jacentes — y compris pour des fonctionnalites que la concurrence avait et que nous n'avions pas. En pratique, le tableau comparatif mentait a cause d'un bug technique, pas seulement d'un texte perime.

Pourquoi nous avons choisi de construire la fonctionnalite, pas seulement de corriger le texte

Pour la surveillance de pages avec connexion, nous avions le choix : corriger le texte (rapide, une heure de travail) ou construire reellement la fonctionnalite (plus d'efforts, mais resout le probleme a la racine). Nous avons choisi la seconde option. Nous avons ajoute une colonne chiffree (AES-GCM) pour le cookie/en-tete d'authentification sur la table des moniteurs, le crawler dechiffre et injecte l'en-tete sur les deux chemins de recuperation (simple et Puppeteer), et detecte l'expiration de session via un code 401/403 ou une redirection vers une page de connexion. Nous l'avons teste de bout en bout sur le propre tableau de bord d'OmniWatchGuard (qui utilise Authorization: Bearer, pas de cookie) avant de republier le texte comme etant vrai.

Ce qui est reste inchange

Tout ce que nous avons trouve incomplet n'a pas ete corrige en le construisant. Le RBAC et le SSO restent sur une vraie roadmap pour 2026 — ils sont marques comme tels, sans ambiguite, et nous ne promettons pas de date precise avant d'avoir reellement commence a y travailler.

Questions frequentes

Pourquoi publier cela au lieu de corriger discretement ?

Parce que le processus lui-meme est utile a d'autres fondateurs solos confrontes au meme ecart naturel entre roadmap et texte marketing, et parce que la transparence sur ce qui est vrai aujourd'hui construit une meilleure confiance que n'importe quel temoignage.

Comment evitez-vous que le meme probleme se reproduise ?

Il n'existe pas encore de processus automatise empechant completement cet ecart — c'est un risque structurel pour tout produit a iteration rapide. Ce qui a concretement change : les notes et temoignages ne peuvent plus etre codes en dur (ils proviennent exclusivement de la base de donnees), et toute nouvelle fonctionnalite mentionnee dans le texte passe par une verification manuelle par rapport au code avant publication.

L'audit a-t-il aussi couvert les pages en anglais ?

Oui, toutes les corrections ont ete appliquees de maniere symetrique sur les versions RO et EN de chaque fichier concerne, y compris le schema JSON-LD utilise par les moteurs de recherche.