Compétence de Rédaction de Blog Sentry

Cette compétence impose les standards de rédaction de blog de Sentry sur chaque publication — que tu aides un ingénieur à écrire son premier article ou qu'un marketeur rédige une annonce produit.

Le standard : Chaque article de blog Sentry devrait être quelque chose qu'un ingénieur senior partagerait dans le Slack de son équipe, ou qu'il référencerait dans une décision technique.

Ce qui suit sont les principes fondamentaux à intérioriser et appliquer à chaque contenu.

La Voix Sentry

Nous sonnons comme : Un développeur senior à une afterparty de conférence expliquant quelque chose qui l'enthousiasme vraiment — intelligent, précis, un peu irrévérencieux, profondément connaisseur.

Nous ne sonnons pas comme : Un blog corporate, un communiqué de presse, un pitch commercial, ou un résumé généré par IA.

Sois techniquement précis, affirme tes opinions, et va droit au but. L'humour est bienvenu mais doit servir le contenu, pas le remplacer. Le sarcasme marche. Une bonne blague par article, c'est suffisant.

Utilise « nous » (Sentry) et « tu/vous » (le lecteur). C'est une conversation, pas un article académique.

Langage Interdit

Ne jamais utiliser ces termes. Ils sont des drapeaux rouges automatiques :

• « Nous sommes ravis/enthousiaste d'annoncer » — annonce, c'est tout
• « Meilleure de sa catégorie » / « leader de l'industrie » / « à la pointe » — montre plutôt que de dire
• « Fluide » / « fluidement » — rien n'est fluide
• « Responsabiliser » / « exploiter » / « déverrouiller » — dis ce que tu veux vraiment dire
• « Robuste » — décris plutôt ce qui la rend robuste
• « Chez [Entreprise], nous croyons que... » — énonce simplement la conviction
• « Rationaliser » — tout le monde rationalise, arrête
• Transitions de remplissage : « Cela dit, », « Il est à noter que, », « À la fin de la journée, », « Sans plus attendre, », « Comme tu le sais peut-être »
• « Dans cet article de blog, nous allons explorer... » — sois direct, commence juste

L'Introduction (2-3 premières phrases)

L'introduction doit faire l'une de deux choses : énoncer le problème ou énoncer la conclusion. Ne jamais commencer par du contexte, l'histoire de l'entreprise, ou du battage.

Bon : « Deux semaines avant le lancement, nous avons tué tout notre produit de métriques. Voici pourquoi la pré-agrégation de métriques time-series échoue pour le debugging, et comment nous avons reconstruit le système de zéro. »

Mauvais : « Chez Sentry, nous cherchons toujours des moyens d'améliorer l'expérience développeur. Aujourd'hui, nous sommes ravis de partager quelques mises à jour passionnantes de notre produit de métriques que nous pensons que tu vas adorer. »

Structure : Suis les Questions du Lecteur

Structure chaque article autour de ce que le lecteur se demande vraiment, pas ton récit interne :

1. Quel problème cela résout-il ? (1-2 paragraphes max)
2. Comment ça marche vraiment ? Pas les boutons à cliquer, mais la technologie sous-jacente. (Gros de l'article — sois précis)
3. Quels étaient les compromis ou les alternatives ? (C'est ce qui sépare le bon du très bon)
4. Comment je l'utilise/l'essaie/l'implémente ? (Prochaines étapes concrètes)

Pour les deep-dives techniques, adresse aussi : 5. Qu'est-ce qu'on a essayé qui n'a pas marché ? (Génère de la confiance) 6. Quelles sont les limitations connues ? (Montre l'honnêteté intellectuelle)

Formatage pour la Lisibilité en Diagonal

Les gens font des scrolls. Les paragraphes plus courts sont presque toujours mieux pour garder les gens en train de lire.

Casse les paragraphes aux points de contraste. Quand une phrase introduit un « mais », « cependant », ou change de perspective, commence un nouveau paragraphe. Ne cache pas le tournant au milieu d'un bloc de texte.

Mauvais :

La surveillance traditionnelle suit les requêtes et la latence. Ça marche pour les services HTTP sans état. Les agents IA sont différents. Une seule exécution peut impliquer plusieurs appels LLM, exécutions d'outils, et transferts.

Bon :

La surveillance traditionnelle suit les requêtes et la latence. Ça marche pour les services HTTP sans état.

Les agents IA sont différents. Une seule exécution peut impliquer plusieurs appels LLM, exécutions d'outils, et transferts.

Le saut de ligne avant le point de contraste crée une emphase visuelle. C'est standard en écriture en ligne même si ça casse les règles de paragraphes traditionnels.

Une idée par paragraphe. Si un paragraphe couvre deux points distincts, sépare-les. Les paragraphes de trois phrases vont bien. Les paragraphes d'une seule phrase vont bien pour l'emphase.

Pas de tirets cadratins. Utilise des virgules, des points, ou des sauts de ligne à la place. Les tirets cadratins vont bien à l'impression mais créent du désordre visuel en formatage de blog.

SEO pour le Contenu Développeur

Quand tu cibles une requête de recherche compétitive :

Commence générique, termine spécifique. Les premiers 50-60 % de l'article devraient être du contenu éducatif agnostique d'outil (définitions, concepts, métriques, bonnes pratiques). Présente ton produit comme un exemple d'implémentation dans la deuxième moitié. Google classifie les guides plus haut que les pages produit pour les requêtes informationnelles.

Mets les mots-clés dans les H2. Les titres génériques sont invisibles pour la recherche. « Métriques clés pour la surveillance d'agents IA » gagne sur « Quoi mesurer ». (Voir Section Headings ci-dessous pour les bons/mauvais exemples.)

Inclus une section définitionnelle. Pour n'importe quel terme principal (« observabilité d'agent », « monitoring d'erreurs »), les pages les mieux classées ont presque toujours une section « Qu'est-ce que X ? ». Inclus-en une même si c'est basique.

Ajoute une FAQ. 3-4 questions ciblant des mots-clés de longue traîne au bas de l'article. Ceux-ci peuvent gagner des featured snippets et les boîtes People Also Ask.

Patterns de Rédaction IA à Éviter

La prose générée par LLM a des signatures. Repère et réécris celles-ci :

Fragments dramatiques saccadés.

• Mauvais : « Pas d'erreurs. Pas d'avertissements. Tout est vert. »
• Bon : « Il n'y avait pas d'erreurs, pas d'avertissements, tout semblait correct. »

Aphorismes en forme de bumper-sticker.

• Mauvais : « Tu ne peux pas réparer ce que tu ne peux pas voir. »
• Bon : « Sans visibilité sur le cycle de vie complet de la requête, tu devines. »

Révélations en trois temps.

• Mauvais : « Pas un problème de config. Pas un bug de code. Le déploiement était obsolète. »
• Bon : « Ce n'était ni un problème de config ni un bug de code. Le déploiement était obsolète. »

Simplicité suffisante.

• Mauvais : [bloc de code] « C'est tout. C'est tout ce dont tu as besoin. »
• Bon : [bloc de code] puis explique ce que le code fait, ou avance simplement.

Parallélisme de structure publicitaire.

• Mauvais : « Les métriques te disent ce qui est cassé. Les traces te disent pourquoi. »
• Bon : « Les métriques montrent ce qui est cassé, mais les traces c'est où tu vas vraiment découvrir pourquoi. »

Personnalité uniquement aux deux extrémités. Les brouillons IA s'ouvrent avec une anecdote personnelle, deviennent impersonnels pendant 80 % de l'article, puis se ferment avec un CTA. La voix de l'auteur devrait persister tout du long.

• Mauvais : Intro personnelle → milieu clinique → « Essaie Sentry gratuitement. »
• Bon : Des asides à la première personne tissés tout au long de l'article : « c'est la partie qui m'a piégé » / « j'aurais accusé le mauvais service ».

Les Titres de Section Doivent Transmettre de l'Information

Faible : « Contexte », « Architecture », « Résultats », « Conclusion »

Fort : « Pourquoi la pré-agrégation time-series détruit le contexte de debugging », « L'approche scatter-gather pour GROUP BY distribué », « Où ça échoue : le mur de cardinalité »

Standards de Qualité Technique

Les chiffres plutôt que les adjectifs. Si tu fais une affirmation de performance, inclus le chiffre.

• Mauvais : « Cela a considérablement réduit notre temps de traitement d'erreur. »
• Bon : « Cela a réduit notre p99 du temps de traitement d'erreur de 340 ms à 45 ms — une amélioration de 7,5×. »

Le code doit fonctionner. Si un article inclut du code, teste-le. Inclus les imports, la configuration, et le contexte. Les commentaires devraient expliquer pourquoi, pas quoi.

Diagrammes pour les systèmes. Si tu décris un système avec plus de deux composants en interaction, inclus un diagramme. Étiquète avec de vrais noms de services, pas des boîtes génériques.

L'honnêteté plutôt que le battage. Ne jamais surreprésenter ce qu'une fonctionnalité fait. Reconnais les limitations. Si quelque chose est en beta, dis-le. Si un concurrent fait quelque chose bien, c'est okay de le noter. Ne prétends pas que les fonctionnalités IA sont plus capables qu'elles ne le sont — « Seer suggère une cause racine probable » ≠ « Seer trouve la cause racine ».

Directives de Titre

Le titre est la phrase au plus grand effet de levier dans l'article. Il doit arrêter un développeur qui scroll dans son RSS feed ou Twitter.

Les titres forts font une affirmation spécifique, racontent une histoire, ou promettent un bénéfice spécifique :

• « Le produit de métriques que nous avons construit a fonctionné. Mais nous l'avons tué et recommencé de zéro quand même »
• « Comment nous avons réduit les délais de version de 5 % en réparant Salt »
• « Ton bundle JavaScript a 47 % de code mort. Voici comment le trouver. »

Les titres faibles sont des annonces vagues :

• « Présentation de notre nouveau produit de métriques »
• « Améliorations de performance dans Sentry »
• « Debugging assisté par IA avec Seer »

La Conclusion

Termine par quelque chose d'utile : un lien vers la doc, le code source, une manière d'essayer, ou un appel pour donner du feedback. Ne jamais terminer par du battage générique (« Nous avons hâte de voir ce que tu construiras ! »), des récaps de ce que tu viens de dire, ou des CTAs de page produit (« Essaie Sentry gratuitement. Inclus sur tous les plans. »). Reconnecte-toi à l'histoire avec laquelle tu as ouvert, ou donne au lecteur quelque chose de concret à faire ensuite.

Types d'Articles

Voici la carte rapide par type d'article :

Le Test « Partagerais-je Cela ? »

Avant de publier, demande-toi : Un développeur partagerait-il cet article ? A-t-il une chance de finir sur Hacker News ? Si la réponse est non, l'article a soit besoin de plus de profondeur, de plus d'insight original, ou il devrait être dans le changelog à la place.

Les articles qui valent la peine d'être partagés contiennent au moins l'un de ceux-ci :

• Une décision technique expliquée avec des compromis
• Des données ou recherches originales introuvables ailleurs
• Une vraie histoire de debugging avec des détails spécifiques
• Un compte rendu honnête de quelque chose qui a mal tourné
• Un how-to qui économise du temps réel au lecteur

Les Non-Négociables (Référence Rapide)

1. Ne jamais publier sans le nom d'une vraie personne. Pas de bylines « L'équipe Sentry ».
2. Ne jamais publier du code qui ne fonctionne pas.
3. Ne jamais dire « nous sommes ravis d'annoncer ». Annonce, c'est tout.
4. Si tu décris un système, inclus un diagramme.
5. Si tu fais une affirmation de performance, inclus le chiffre.
6. Si tu discutes une décision, explique ce que tu n'as pas choisi et pourquoi.
7. Chaque article doit avoir un clair « pour qui c'est ? » dans l'esprit de l'auteur avant écriture.
8. Les changelogs appartiennent au changelog. Les articles de blog devraient offrir plus.
9. Quand tu doutes, approfondis. Le risque d'être trop superficiel est bien plus grand que d'être trop détaillé.
10. Écris l'article que tu aurais souhaité trouver en essayant de résoudre ce problème.

Quand Tu Révises ou Édites un Brouillon

Parcoure les deux checklists :

Revue Technique :

• Tous les claims techniques sont corrects
• Les échantillons de code fonctionnent
• Les descriptions d'architecture correspondent à la réalité
• Les chiffres et benchmarks sont corrects
• Pas de sursimp qui ferait grimacer un expert

Revue Éditoriale :

• L'introduction accroche le lecteur dans 2 phrases
• Passe le test « partagerais-je cela ? »
• Pas de langage corporate, de remplissage, ou de fluff
• Les titres transmettent de l'information
• Longueur appropriée (pas gonflée, pas trop mince)
• Le titre est spécifique et convaincant

Vérification Finale :

• Le byline de l'auteur est correct (nom d'une vraie personne)
• Les liens vers la doc/getting-started sont inclus
• L'article ne duplique pas ce qui est dans le changelog

Quand tu fournis du feedback, sois spécifique et constructif. Cite le passage faible, explique pourquoi c'est faible, et réécris-le pour montrer le standard.