Méthodologie

La règle des trois semaines

Avant qu'une revue soit publiée sur Taverne, l'outil doit avoir été utilisé activement trois semaines minimum, sur un cas d'usage réel — pas sur un projet de démonstration construit pour la revue.

Pourquoi trois semaines : c'est la fenêtre où la lune de miel s'efface et où les vrais frottements émergent. La latence imprévisible, les limites de quota qu'on tape sans s'y attendre, le bug d'export qui ne se manifeste que sur un fichier de plus de 50 Mo. Une revue d'une semaine est une publicité déguisée.

Pour les guides et comparatifs, la règle est plus souple — il faut avoir utilisé chaque outil cité dans la durée, mais pas nécessairement trois semaines sur chacun.

Critères systématiques de test

Chaque revue couvre, au minimum, ces dimensions :

Dimension	Ce qu'on cherche
Qualité du résultat	Justesse, fluidité, capacité à comprendre les nuances québécoises et françaises
Vitesse	Latence moyenne, p95 sur les tâches lourdes
Limites concrètes	Quotas, taille de contexte, refus systématiques, hallucinations notables
Intégrations	Avec quel autre outil de votre stack ça marche, ou ne marche pas
Confidentialité	Politique de réutilisation des données, options enterprise, conformité Loi 25
Prix réel	Pas le prix marketing — le coût annualisé sur un usage typique de PME
Support	Délai de réponse, qualité des humains derrière (vrais retours, pas chatbots)
Évolution	Cadence des updates, churn de fonctionnalités, signaux de stabilité de l'éditeur
Adoption Québec	Combien de PME québécoises l'utilisent dans notre cercle, retours qualitatifs
Alternatives	Au moins deux concurrents directs comparés sur le même cas d'usage

Sources et fact-checking

Tout chiffre, toute citation, toute date dans nos articles provient de l'une de ces sources :

• Documentation officielle de l'éditeur, lien direct dans l'article.
• Page de tarifs publique, vérifiée à la date indiquée dans la fiche outil.
• Recherche structurée NotebookLM pour les sujets larges (état du marché, comparaisons multi-acteurs, historique).
• Tests internes avec captures d'écran d'origine, jamais des images génériques de stock.
• Conversations directes avec PME québécoises utilisatrices — citées avec leur permission.

Le composant attributable_facts sur les fiches outils stocke chaque claim avec sa source et sa date de dernière vérification.

Cycle de fraîcheur — 90 jours

Un article publié n'est pas figé. Tous les 90 jours, chaque fiche outil et chaque revue traverse un check rapide :

1. Re-vérification automatique des prix (script verify-pricing avec Claude Haiku, ouverture d'une PR si écart).
2. Re-vérification manuelle des liens d'affiliation (cron quotidien complémentaire).
3. Mise à jour des captures d'écran si l'interface a changé visiblement.
4. Ajout d'un bloc Mise à jour [date] pour signaler les changements substantiels.
5. Mise à jour du champ dateModified dans le schema:Article.

En pied de chaque article apparaît : Publié le [date] · Mis à jour le [date]. C'est le signal de fraîcheur le plus pondéré par Google et par les LLMs en 2026.

Indépendance éditoriale

On l'a déjà dit dans la page transparence, on le redit ici parce que ça compte :

Aucun éditeur, aucun programme d'affiliation, aucune commission ne change le verdict d'une revue. Si un outil qu'on a recommandé se dégrade, l'article est mis à jour pour le refléter — y compris pour retirer la recommandation.

Erreurs et mécanisme de correction

Si vous voyez une erreur factuelle dans un article, écrivez à david_cyr@hotmail.fr avec :

• L'URL exacte de l'article concerné.
• La phrase ou le chiffre incorrect.
• Votre source pour la correction (lien officiel, capture, document daté).

On corrige sous 7 jours pour les erreurs factuelles claires, sous 30 jours pour les corrections nécessitant un test ou une vérification approfondie. Toute correction substantielle est mentionnée dans l'article — pas en silence.