Parler de bienveillance dans le code, c’est une chose.
La pratiquer dans nos revues, nos échanges, nos feedbacks, c’en est une autre.

Parce qu’un commentaire, c’est plus qu’une remarque technique.
C’est un message adressé à une personne. Et de la qualité de ce message dépend souvent la fluidité de la collaboration, la confiance, et même la vitesse de livraison.

Conventional Comments propose une approche simple et structurée pour écrire des commentaires clairs, constructifs et respectueux. Une sorte de “grammaire commune” pour communiquer dans nos revues de code sans perdre ni le fond, ni la forme.

---

🧩 Une structure au service de la clarté

Le principe est simple : chaque commentaire commence par un label qui explicite l’intention.

Quelques exemples :

• praise: pour valoriser un bon choix ou un travail soigné
• suggestion: pour proposer une amélioration
• issue: pour signaler un problème précis
• question: pour demander une clarification
• thought: pour ouvrir une réflexion

À ces labels peuvent s’ajouter des modificateurs comme (blocking) ou (non-blocking) qui précisent le niveau d’urgence.
L’objectif est clair : éviter les malentendus, fluidifier la lecture, rendre explicite ce qui est souvent implicite.

C’est un format minimaliste, mais puissant. Il permet à chacun de savoir instantanément si un commentaire demande une action, une discussion, ou simplement invite à réfléchir.

---

🤝 Le commentaire comme acte de bienveillance

Un bon commentaire n’est pas une critique, c’est une conversation.
Il part d’une intention : comprendre, aider, améliorer.

Dire suggestion: plutôt que “tu devrais faire comme ça” change tout.
Écrire praise: pour reconnaître un bon choix, c’est reconnaître la compétence avant de pointer la correction.
Et un question: posé avec curiosité crée plus d’échanges qu’une remarque sèche.

La bienveillance, ici, n’est pas un mot doux : c’est une méthode de communication technique.
C’est celle qui transforme les revues de code en apprentissage collectif, qui renforce la sécurité psychologique, et qui nourrit la confiance entre développeurs.

---

⚙️ Vers une culture de revue constructive

Mettre en place Conventional Comments dans une organisation, c’est un choix culturel avant d’être un choix méthodologique.
Cela signifie :

• Former les équipes à la posture derrière les commentaires : écouter, expliquer, reformuler.
• Documenter la convention dans les guidelines d’ingénierie.
• Outiller les équipes avec des modèles de commentaires (praise:, issue(non-blocking):, suggestion:…).
• Valoriser les bonnes pratiques dans les revues de sprint ou les rétrospectives.

Avec le temps, ces micro-gestes changent la nature des échanges. Les revues deviennent plus calmes, plus efficaces, plus utiles.
Les développeurs se sentent écoutés, les discussions se concentrent sur le fond, et la qualité du code s’en ressent.

---

🧭 Mon regard de VP Engineering

Pour moi, Conventional Comments incarne une idée forte : le style de nos échanges est une partie intégrante de notre ingénierie.
Il ne s’agit pas de polir la forme, mais de maîtriser un outil de communication aussi essentiel que le code lui-même.

Dans une équipe, la rigueur technique ne suffit pas.
Il faut de la clarté, du respect, de la pédagogie.
Et c’est précisément ce que cette approche formalise : une exigence de précision, au service du collectif.

Adopter Conventional Comments, c’est professionnaliser la bienveillance.
C’est transformer chaque commentaire en opportunité d’apprentissage, chaque désaccord en dialogue, chaque revue en moment de croissance commune.

C’est, au fond, continuer à construire ce que j’appelle une culture d’ingénierie humaine.

---

Sources
• https://conventionalcomments.org
• https://www.sfeir.dev/front/conventional-comments
• https://conventionalcomments.org/communication