Collaboration

Situation réelle Code review : rituel quotidien qui peut faire progresser l’équipe… ou créer de la frustration. Cette situation n’est pas une fatalité. Un code review efficace peut être un accelerator : knowledge sharing, quality improvement, team cohesion. Ce que j’ai observé : beaucoup de code reviews sont frustrantes. Pour l’auteur (09h00 crée PR, 16h30 pas review, lendemain 14h enfin review, 16h00 corrige commentaires, lendemain 11h 2ème review nouveaux comments, 5 jours merger 200 lignes). Pour le reviewer (PR à reviewer 1500 lignes “Où commencer ?” “Trop gros comprendre” “Approve en diagonale”). Résultat: vélocité ralentie, frustration deux côtés, quality compromise. Un code review efficace nécessite small PRs <400 lignes, fast feedback <24h, constructive comments, celebrate good code. ...

Dédramatisation “Lisez la doc.” Mais quelle doc ? Celle écrite il y a 2 ans et obsolète depuis 18 mois ? Cette situation n’est pas une fatalité. Voici comment créer une documentation que les développeurs vont réellement lire et maintenir. Ce que j’ai observé : le problème Doc obsolète inexistante. Symptômes classiques (README.md Last updated 2021 Run npm install Mais projet utilise pnpm depuis 2023 Ou pire Fichier user.service.ts 500 lignes Commentaire Aucun README “Le code se documente lui-même” Résultat Nouveaux devs perdus Bugs incompréhension Temps perdu reverse-engineer). Documentation n’est pas optionnelle. C’est multiplier : Onboarding 3x plus rapide Bugs -50% meilleure compréhension Contributions facilitées. Principes : Code self-documenting d’abord, Documenter “Pourquoi”, Rester proche code, Tester maintenir. Commencer petit : README Quick Start 1h, Guides essentiels 1 jour, CI check docs 2h, Iterate feedback. ...

Situation réelle Pourquoi cette décision a été prise ? Qui l’a validée ? La documentation ne le dit pas… ou elle est obsolète. Cette situation n’est pas une fatalité. Les ADR et RFC résolvent ce problème de façon élégante. Ce que j’ai observé : beaucoup d’équipes ont une documentation morte. Symptômes classiques (README.md last updated 2 years ago “We use microservices…” mais personne ne sait pourquoi microservices quelles alternatives considérées qui a décidé). Résultat: décisions refaites plusieurs fois, contexte perdu, nouveaux arrivants perdus. Avec ADR/RFC, documentation vivante : toujours à jour archives immutables, contexte préservé, décisions traçables. Métriques adoption mesurée (Avant ADR/RFC décisions documentées 10% “Pourquoi ?” répondu rarement onboarding nouveau 2 semaines, Après ADR/RFC décisions documentées 95% “Pourquoi ?” dans ADR toujours onboarding nouveau 3 jours). ...

Situation réelle La relation entre Product Management et équipes techniques est souvent tendue. D’un côté, la pression business et les deadlines. De l’autre, la complexité technique et la qualité du code. Cette tension n’est pas une fatalité. Ce que j’ai observé : la collaboration Product-Tech efficace n’est pas un idéal inatteignable. Elle repose sur communication structurée, traduction mutuelle, objectifs alignés, confiance. Arrêter de voir PM vs Tech comme une opposition. C’est PM + Tech qui crée de la valeur. Cette synergie devient votre avantage compétitif quand vos concurrents se disputent encore en interne. ...

Dédramatisation “Deux développeurs pour une seule tâche, c’est du gaspillage !” Cette réaction revient souvent. Pourtant, après avoir pratiqué le pair programming dans différents contextes - de la startup agile à l’entreprise traditionnelle, en présentiel et en remote - je peux affirmer que c’est l’une des pratiques les plus transformatrices pour la qualité du code et la montée en compétence d’équipe. Ce que j’ai observé : le pair programming mal fait peut effectivement être improductif et frustrant. Mais le pair programming bien fait peut être un accelerator : knowledge sharing, quality improvement, team cohesion. Son succès dépend moins de la technique que de la culture d’équipe et de la qualité des interactions humaines. L’investissement initial en temps et énergie est réel, mais les bénéfices à moyen terme (qualité code, partage connaissances, réduction risques) en font souvent une pratique rentable. ...

Situation réelle “Tu peux jeter un œil à ma PR ?” Cette phrase déclenche souvent une appréhension sourde. Côté auteur : peur du jugement, stress de l’exposition. Côté reviewer : charge mentale, responsabilité de la qualité. Ce que j’ai observé : après avoir participé à des milliers de code reviews, les équipes les plus performantes ne sont pas celles qui ont les reviews les plus strictes, mais celles qui ont développé une culture bienveillante d’amélioration continue. ...

Inspiré du chapitre “Les nouvelles attentes des recruteurs” du livre “En quête d’expérience”. Dédramatisation “Excellent techniquement mais…” Cette phrase, je l’ai entendue cent fois en entretiens de débriefing. Le “mais” tue plus de carrières que les bugs. Mais ce n’est pas une fatalité. Les soft skills ne sont pas des talents innés, ce sont des compétences qui se développent avec la pratique. Ce que j’ai observé : en 2025, maîtriser React ne suffit plus. Le marché valorise de plus en plus la collaboration et la communication. Mais cela ne signifie pas que vous devez être extraverti ou charismatique. Les soft skills techniques (communication claire, empathie, écoute active) sont différentes des soft skills sociales générales. ...

Situation réelle “Pourquoi ce bouton est-il différent sur cette page ?” Cette question, tout développeur frontend l’a déjà entendue. Et derrière cette apparente broutille se cache un problème plus profond : l’absence de référentiel commun entre les équipes design et développement. Ce que j’ai observé : après avoir participé à la mise en place de plusieurs Design Systems, je peux affirmer que leur valeur dépasse largement la cohérence visuelle. Ils transforment la façon dont les équipes collaborent et accélèrent significativement les cycles de développement. Sur un projet récent, nous avons mesuré un gain de 40% sur le temps de développement des interfaces après implémentation du Design System. Les développeurs passaient moins de temps sur le styling et plus sur la logique métier. ...

Situation réelle “On va faire du pair programming systématique.” Six mois plus tard : équipe épuisée, vélocité divisée par deux, talents partent. Le pair programming imposé sans discernement peut détruire autant qu’il peut aider. Ce que j’ai observé : le pair programming est un outil puissant dans certains contextes, contre-productif dans d’autres. Le problème n’est pas l’outil, c’est l’usage dogmatique. Le faux problème Le faux problème serait de croire que pair programming = toujours mieux. En réalité, c’est un outil à utiliser dans des situations spécifiques, pas une religion. ...

Situation réelle Commentaire sur une pull request : “Ça, c’est du code de junior. Refais tout.” Le développeur ne contribuera plus jamais avec la même confiance. La code review vient de passer d’outil de qualité à arme de destruction. Ce que j’ai observé : la code review est l’un des rituels les plus puissants pour la qualité ET la culture. Elle peut construire ou détruire. Rarement neutre. Le faux problème Le faux problème serait de croire que la code review sert uniquement à trouver des bugs. En réalité, elle sert à partager connaissance, aligner standards, et renforcer culture. ...