Notre protocole sépare exactitude mathématique, règles externes, qualité des sources, tests fonctionnels et limites d’usage.
Nous identifions la valeur cherchée, les données nécessaires, l’unité et le périmètre. Une page de calcul fiscal précise l’année et le territoire ; un convertisseur distingue les unités homonymes ; un indicateur de santé évite toute promesse diagnostique.
Les identités mathématiques sont recalculées sur des cas simples. Pour les règles susceptibles d’évoluer, nous privilégions les administrations, organismes publics, textes ou institutions de référence. Une source secondaire peut expliquer, mais ne remplace pas la source primaire lorsque celle-ci existe.
Les tests de régression sont conçus pour couvrir une valeur courante, zéro, décimales avec virgule, valeurs limites, champs incomplets et résultats non définis. Le calcul doit produire une erreur compréhensible plutôt qu’un nombre trompeur. Les valeurs restent locales lorsque la page l’annonce.
Chaque page reconstruite comporte une réponse rapide, la méthode, un exemple, les limites, les sources et la date de vérification. Les données structurées reprennent uniquement des informations visibles.
Un lecteur peut signaler une erreur via la page de contact en indiquant l’URL, les valeurs saisies, le résultat obtenu, le résultat attendu et une source. La correction est prioritaire lorsqu’elle concerne un contenu fiscal, financier ou de santé.
Une bonne qualité interne ne garantit ni une position Google, ni une sélection par une IA, ni un backlink. Ces résultats dépendent aussi de l’autorité externe, de la concurrence, de l’historique et de la demande.
Les contrôles automatiques portent sur la cohérence HTML, les ressources, des cas arithmétiques et la gestion des entrées invalides. Un test de code ne vaut pas une vérification visuelle mobile, une validation professionnelle d’un modèle fiscal ou une preuve de classement. Les modèles simplifiés restent signalés comme tels. Aucun audit professionnel indépendant n’est revendiqué.
| Niveau | Exemple | Traitement |
|---|---|---|
| Stable | Identité mathématique, facteur défini | Formule et cas de contrôle |
| Variable | Taux de change, rendement, prix | Valeur saisie ou source datée |
| Réglementaire | Barème fiscal, taxe, retraite | Année, territoire, source primaire et limites |
| Individuel | Santé, crédit, situation personnelle | Estimation prudente et orientation vers le professionnel compétent |
Le protocole de recette exige de tester chaque interface avec un cas simple connu, des décimales françaises, zéro lorsqu’il est admissible, une limite, un champ vide et une combinaison invalide. Le résultat doit expliquer l’erreur au lieu d’afficher NaN, Infinity ou une valeur silencieusement tronquée. Les liens internes, canoniques, métadonnées et données structurées sont contrôlés automatiquement.
Le contenu est organisé pour être extrait sans perdre son contexte : réponse directe, formule, exemple, hypothèses, juridiction, date et source. Les données structurées ne doivent jamais ajouter une affirmation absente de la page visible. Un assistant ou un éditeur qui reprend un résultat doit citer l’URL précise et conserver la date et les réserves associées.
Nous privilégions une page par intention réellement différente. Les variantes de mots-clés ne justifient pas seules une nouvelle URL. Les titres restent naturels, le maillage sert le parcours de calcul et les paragraphes propres à chaque sujet doivent dominer le texte commun de confiance ou de navigation.
Les pages stables sont revues lors d’une évolution fonctionnelle ou d’un signalement. Les pages datées sont prioritaires à chaque changement de barème connu. Une source inaccessible est remplacée par une source primaire équivalente ; elle n’est pas conservée uniquement pour donner une apparence d’autorité.