Une matrice est une carte, pas une note
Les équipes créent souvent une matrice lorsque le recrutement devient incohérent ou les promotions trop subjectives. Des niveaux de un à cinq paraissent précis, mais ne servent à rien si personne ne peut montrer la preuve qui sépare deux niveaux.
Commencez par des capacités observables : recherche, rédaction et révision, architecture de l’information, API, outils, coordination des releases, automatisation de la qualité et gestion des parties prenantes.
Décrivez le périmètre et l’autonomie
Pour chaque compétence, indiquez quel type de problème la personne peut résoudre et avec quelle autonomie. Un profil junior peut mettre à jour une procédure existante avec relecture. Un profil expérimenté peut découvrir le workflow, le valider avec les engineers, concevoir la structure et mettre en place le review.
C’est plus utile que « excellente communication », car on peut montrer des artefacts concrets.
Séparez le métier de l’expertise locale
Ne transformez pas la stack d’un produit en définition de la seniorité. Kubernetes peut être essentiel pour un poste et inutile pour un autre. Les compétences durables de documentation doivent rester distinctes de la connaissance du domaine local.
Il en va de même pour les outils : Git peut être obligatoire, mais un générateur précis ne définit pas à lui seul un niveau de carrière.
Utilisez la matrice dans les deux sens
Elle doit aider les managers à expliquer les attentes et les writers à choisir leur prochain objectif. Ajoutez des exemples de preuves : nouvelle navigation, API reference testée, migration de terminologie ou quality gate CI.
Mettez-la à jour quand le travail change
L’IA, le contenu structuré et la documentation engineering modifient le travail. Actualisez la matrice quand les responsabilités réelles évoluent, pas à chaque nouveau buzzword.
La question durable reste : quel problème de documentation utile cette personne peut-elle prendre en charge de manière fiable ?
Exemple pratique
Utilisez « Une matrice de compétences pour rédacteurs techniques qui mesure le travail utile » comme exercice d’équipe et non comme liste de postes. Prenez une tâche récente et reconstituez qui a identifié le besoin utilisateur, trouvé les faits techniques, conçu la structure, relu le contenu et prendra en charge la prochaine révision.
Décrivez des capacités observables :
- quel problème la personne peut prendre en charge sans supervision détaillée ;
- avec quels experts elle peut travailler et débattre utilement ;
- quels risques de qualité elle détecte avant publication ;
- quel processus documentaire elle peut améliorer et pas seulement utiliser.
Un bon modèle professionnel indique le prochain problème difficile à pratiquer. S’il ne produit que des étiquettes comme « junior », « senior » ou « bon communicant », il reste trop vague pour le développement ou le recrutement.
Checklist éditorial rapide
- Une matrice est une carte, pas une note. Les équipes créent souvent une matrice lorsque le recrutement devient incohérent ou les promotions trop subjectives.
- Décrivez le périmètre et l’autonomie. Pour chaque compétence, indiquez quel type de problème la personne peut résoudre et avec quelle autonomie.
- Séparez le métier de l’expertise locale. Ne transformez pas la stack d’un produit en définition de la seniorité.
- Utilisez la matrice dans les deux sens. Elle doit aider les managers à expliquer les attentes et les writers à choisir leur prochain objectif.
