Deux devs, même module, zéro communication

Premier jour dans une nouvelle boite.

Je m'installe, je regarde l'équipe, et je remarque Thomas et Léa.

Deux devs. Même équipe. Assis à 1 mètre l'un de l'autre.

Thomas refactorisait le module de paiement depuis 3 jours. Léa développait une nouvelle intégration sur ce même module depuis... 3 jours.

Personne ne le savait. Ni l'un, ni l'autre.

Je l'ai découvert en faisant ma première code review. Deux branches parallèles, deux approches différentes, 6 jours de dev cumulés sur le même périmètre.

Ce n'est pas un problème de communication

Voilà le truc que tout le monde se dit en voyant cette histoire : "Ils auraient dû se parler."

Oui, évidemment. Mais ce n'est pas le vrai problème.

Thomas n'a pas pensé à parler à Léa parce que personne ne lui avait dit que c'était important. Léa n'a pas signalé ce qu'elle faisait parce qu'elle ne savait pas que quelqu'un d'autre y travaillait. Ce n'est pas de la négligence. C'est l'absence d'un cadre qui rend l'information visible naturellement.

Quand on te dit "va bosser sur le paiement", tu vas bosser sur le paiement. Si l'équipe n'a pas mis en place un système où tu dois d'abord annoncer ce que tu fais, et où tu vois ce que font les autres, tu n'y penses tout simplement pas.

Ce que j'ai mis en place la semaine suivante

1. Un daily de 10 minutes, debout, sans Jira ouvert

Pas pour reporter l'avancement à un manager. Pour que Thomas sache ce que fait Léa, et inversement. Juste ça.

On ne parle pas de roadmap, de OKR, ni de deadline. On parle de ce sur quoi on travaille en ce moment. "Léa, tu fais quoi?" "Je refactor l'intégration de paiement." "Oh merde, j'étais en train de faire pareil."

10 minutes. Debout, parce que c'est plus rapide. Pas sur Jira, parce qu'on n'a pas besoin de formalisme : c'est une conversation humaine.

2. Un board visible par tous, en temps réel

Pas pour micro-manager. Pour que les dépendances entre sujets soient visibles avant qu'elles deviennent des conflits de merge.

N'importe quel tool simple suffit : un tableau blanc, un Trello, un Jira bien utilisé. Ce qui compte, c'est que tout le monde peut voir en une seconde sur quoi chacun travaille. Pas besoin que ce soit parfaitement tenu à jour. Juste assez transparent pour voir les chevauchements.

3. Une règle simple : avant de commencer un chantier, en parler 2 minutes

Pas une réunion. Une conversation. Le genre que Thomas et Léa n'avaient jamais eu parce que personne ne leur avait dit que c'était important.

"Yo, je vais commencer sur le paiement." "Ah, je te conseille de pas toucher X, Léa le fait en ce moment."

Deux minutes. Ça change tout.

Pourquoi ce n'est pas un problème de communication, mais de structure

La différence est subtile mais décisive.

Un "problème de communication" suppose que les gens ne parlent pas assez, qu'ils ne sont pas assez transparents, qu'il manque de bienveillance. C'est généralement faux.

Un problème de structure c'est : tu n'as pas mis en place le cadre qui rend l'information visible naturellement. Les gens ne partagent pas ce sur quoi ils travaillent, pas parce qu'ils sont fermés, mais parce que tu ne le leur as jamais demandé de manière systématique.

Dire "communiquez mieux" à une équipe sans structure, c'est dire "nage mieux" à quelqu'un dans une piscine sans eau.

La structure, c'est ce qui transforme l'exception (une conversation spontanée) en règle (un rituel clair).

Comment ça se manifeste dans les vraies équipes

Ce genre de situation arrive plus souvent qu'on le croit. J'en vois au moins une variation par mois :

Variante 1 : Deux features parallèles qui pourraient être fusionnées Alice développe une API d'export. Bob développe un système de rapports. C'est le même travail, à 80%. Découvert pendant la review de merge.

Variante 2 : La dette technique invisible Quelqu'un refactor un système "discrètement" pendant qu'un autre s'appuie sur le comportement actuel en le modifiant. Merge conflict pas possible, mais incompatibilité totale.

Variante 3 : La perte de momentum Tu dis "je vais explorer une solution" mais tu dis pas à qui. Deux semaines plus tard, quelqu'un d'autre explore la même chose, en parallèle. Vous avez perdu deux semaines, ensemble.

Variante 4 : Le blocage silencieux X a besoin que Y finisse quelque chose. Mais il ne le sait pas. Il attend passivement. Y fait autre chose. Personne n'a de visibilité. Deux semaines se transforment en un mois.

Tout ça disparaît quand la structure est en place.

La vraie différence : visibilité avant gestion

Une équipe sans structure, c'est une équipe où tu découvres les problèmes quand ils deviennent des crises de merge.

Une équipe avec structure, c'est une équipe où tu vois les problèmes avant qu'ils arrivent. Thomas aurait dit à Léa le deuxième jour. Plus besoin de résoudre un conflit, juste de décider qui fait quoi.

Ce que j'installe, ce n'est pas un système de reporting. C'est un système de visibilité.

La gestion vient après. Si tu vois un problème - deux devs sur le même truc - tu peux le régler avant qu'il coûte 6 jours de travail.

Ce que je fais vraiment en mission CTO hands-on

Beaucoup de gens pensent que je viens coder. Que je viens architecting des systèmes compliqués ou que je vais livrer une feature complexe.

Parfois oui. Mais ce que j'installe d'abord, c'est le cadre.

Je mets en place les rituels qui font que l'équipe fonctionne sans moi. Pas pour m'en aller plus vite. Pour que l'équipe soit autonome et efficace.

C'est exactement ce que je fais avec Thomas et Léa :

• Un daily pour la visibilité
• Un board pour la structure
• Une règle simple pour l'anticipation

Trois choses. Zéro infrastructure. Zéro outils complexes. Juste du bon sens systématisé.

En conclusion : la structure se voit aux petites choses

Une bonne équipe ne se reconnaît pas à ses technologies. Elle se reconnaît à ses rituels.

Pas des rituels usine à gaz. Des rituels simples, systématiques, qui rendent visible ce qui est important.

Thomas et Léa n'étaient pas negligents. Ils n'étaient juste pas encadrés. Quand tu leur donnes le cadre, le reste se fait tout seul.

C'est ça la vraie leadership technique : pas construire des systèmes compliqués. C'est mettre en place le cadre qui fait que ton équipe livrer plus avec moins d'effort et de friction.

Et franchement? C'est la partie la plus impactante du job.

---

P.S. : Si vous reconnaissez Thomas et Léa dans votre équipe, vous savez quoi faire. Demain matin, réunissez vos devs 10 minutes. Parlez de ce sur quoi chacun travaille. C'est tout ce dont vous avez besoin pour commencer.