Contribuer au blog DOG&DEV et bonnes pratiques pour les tutoriels techniques

Ce guide s’adresse à celles et ceux qui souhaitent proposer un article ou une idée de tutoriel pour le blog DOG&DEV, ou simplement rédiger des tutoriels techniques de qualité. Il décrit une structure type, les bonnes pratiques (prérequis, commandes, dépannage, ton) et une procédure générale pour contacter l’équipe. La procédure exacte (Git, formulaire, email) peut évoluer ; ce document en pose les bases.

À qui s’adresse ce guide

• Auteurs souhaitant proposer un tutoriel au blog DOG&DEV.
• Rédacteurs techniques (internes ou externes) qui veulent aligner leurs articles sur une structure et un ton cohérents.

Structure type d’un tutoriel technique

1. Titre : clair, descriptif, avec les mots-clés principaux (outil, version, objectif).
2. Introduction : contexte, objectif (ce que le lecteur saura faire à la fin), public (débutant, admin, dev).
3. Prérequis : OS, versions, accès (root, compte admin), logiciels déjà installés.
4. Étapes :
   • Numérotées ou en sous-titres.
   • Commandes complètes (copier-coller possible), avec commentaires si besoin.
   • Fichiers de config : extraits pertinents, noms et chemins exacts.
   • Captures d’écran : optionnel, indiquer par <!-- TODO: capture --> ou équivalent si à ajouter plus tard.
5. Dépannage : tableau Symptôme | Cause possible | Correctif pour les erreurs fréquentes.
6. Bonnes pratiques : sécurité, sauvegardes, mises à jour, liens vers des articles connexes.
7. Ressources : doc officielle, liens de référence (sans promouvoir une marque ou un hébergeur tiers de manière non pertinente).

Bonnes pratiques de rédaction

• Ton : technique, clair, orienté « on partagne notre expertise ». Éviter le jargon non défini ; expliquer les acronymes la première fois.
• Commandes et blocs de code :
  • Préfixer les blocs avec le langage ou le shell : ```bash, ```powershell, ```sql, etc.
  • Donner les commandes complètes ; préciser si elles sont à lancer en root ou en utilisateur.
• Tableaux : format GFM (Markdown) pour le dépannage et les récap.
• Liens internes : vers d’autres articles du blog (ex. « Pour la configuration MySQL, voir fivem-sql. ») quand c’est pertinent.
• Pas de contenu promotionnel pour des marques ou hébergeurs non liés au sujet. Les références à DOG&DEV et à ses partenaires (AnHosting, etc.) restent discrètes et en cohérence avec le positionnement du blog.

Format et support

• Format : Markdown avec frontmatter YAML (title, description, date, author, tags).
• Description : 120–160 caractères environ, pour le SEO et les listes d’articles.
• Signature (optionnelle) en fin d’article :
  « Cet article s’inscrit dans notre série de guides hébergement et gaming. Pour un serveur sur-mesure, contact. »

Proposer un article ou une idée à DOG&DEV

• Procédure (à adapter selon l’évolution du blog) :
  • Envoyer un résumé (titre, objectif, public, plan en 5–10 lignes) à contact@doganddev.eu.
  • Ou, si une procédure de contribution ( dépôt Git, PR, formulaire) est en place, la suivre comme indiqué sur le site.
• Thématiques : hébergement, VPS, gaming (Minecraft, FiveM, GMod, Rust, etc.), Windows/Linux, Plesk, Proxmox, bases de données, mail, scripting, bonnes pratiques.
• L’équipe DOG&DEV se réserve le droit d’accepter, de refuser ou de demander des modifications.

Bonnes pratiques générales

• Vérifier les informations (versions, commandes, liens) avant publication.
• Mettre à jour les articles existants si une procédure change (nouvelle version, dépôt, option).
• Citer les sources (doc officielle, forums) lorsqu’on s’inspire fortement d’un contenu existant.

Ressources

• DOG&DEV — site et contact.
• Documentation des outils mentionnés dans les tutoriels (à lier dans chaque article).

Cet article s’inscrit dans notre série de guides hébergement et gaming. Pour un serveur sur-mesure, contact.