Sans prétendre avoir la vérité absolue sur la question de la confiance en équipe, je vous partage mes réflexions issues de la dizaine d'équipes que j'ai pu intégrer. Je vais surtout me concentre sur les équipes de développements, mais dans les faits, je pense que pas mal de choses peuvent s'appliquer à d'autres équipes, car le plus souvent les problèmes de confiance viennent d'un manque de communication ou d'un manque de bon sens pas d'un problème de développement.
Laissez l'équipe recruter l'équipe !
En général c'est quelqu'un de plus ou moins extérieur à l'équipe qui recrute pour l'équipe. Donc ça fait 6 mois / 1 an qu'on bosse ensemble à 5 personnes, quelqu'un débarque un lundi matin "Bonjour c'est moi qui rejoins l'équipe !", une personne qu'on rencontre vraiment pour la première fois, avec qui on échange pour la première fois, et on doit l'intégrer en combinant nos attentes aux siennes sans qu'on en ait discuté avant. Vraiment c'est ça le meilleur choix ?
Ça peut paraitre bête, mais je trouve que laisser les équipes choisir qui va les rejoindre, en faisant faire les entretiens aux membres de l'équipe, est super efficace. Déjà parce que c'est en faisant les entretiens qu'on découvre que c'est difficile de recruter quelqu'un je trouve, ensuite c'est le meilleur moyen de juger du mindset de la personne, de si ça peut matcher avec l'équipe, de ce qu'elle sait pour les besoins réels de l'équipe (si on a besoin d'un expert React dans l'équipe, quelqu'un d'expert en PHP Symphony ça va pas le faire… par contre si on a besoin d'augmenter la force de frappe de l'équipe, que la personne a envie de faire du React, a déjà un peu regardé et on sent va monter en compétence ça se réfléchit).
À mon sens, j'ai déjà remarqué qu'une équipe qui fonctionne bien, c'est aussi une équipe qui connait ses points forts mais aussi ses limites, c'est souvent des équipes qui savent naturellement dire "il nous manque un expert…", ou "on a besoin de monter en compétence sur…". Si une équipe est à ce stade-là, ça devient naturel de savoir repérer en entretien une nouvelle personne.
Je trouve particulièrement catastrophique d'avoir un service RH qui fait du recrutement qui va catapulter dans les équipes des nouvelles personnes. Encore plus en informatique que dans d'autres secteurs où les gens autour de l'équipe ne comprennent souvent pas du tout le métier, ses subtilités, comment on travaille.
Je pense aussi que seul quelqu'un qui vit l'usage d'une technologie peut vraiment évaluer quelqu'un qui dit maitriser.
En entretien j'ai déjà vu un "expert React avec 5 ans d'expérience", moi "est-ce que tu peux m'expliquer ce que c'est le Virtual DOM ?" (si vous n'avez jamais fait de React : c'est la base de la base), lui "euh... mytho, mytho, mytho", moi "tu saurais me dire la différence entre un function component et class component ?" (si vous n'avez jamais fait de React : c'est aussi la base, surtout vers 2019/2020 ou la plupart des projets mixaient les deux comme c'était une phase de transition), lui "euh… mytho, mytho, mytho". Je savais que c'était fini à ce moment-là, on cherchait quelqu'un de bon en React pour se renforcer là-dessus, on était une équipe soudée où on se disait les choses en toutes honnêtetés, comment on pouvait faire confiance à quelqu'un qui survend ses compétences et nous mens en entretien ?
Autre cas, toujours dans la même équipe. À l'époque la première question qu'on posait car ça permet de lancer une discussion c'était "C'est quoi le dernier framework de test que tu as utilisé ?", peu importe la réponse même "j'ai jamais pu faire de test" en vrai, pour peu qu'on peut discuter. Là le candidat me sort "Aucun. Je fais pas de test. Ça sert à rien.", nous "Tu peux nous en dire plus sur pourquoi ça sert à rien ?" (au cas où), lui "Mon travail c'est coder, pas tester, y'a des gens dont c'est le taff" (en gros). Dès la plaquette de présentation du contexte c'était indiqué plusieurs technos de tests, parce que c'était important dans la culture de l'équipe. Vous vous en doutez : pour moi c'était fini. Mais l'entretien a continué avec d'autres dingueries du genre.
Toujours dans la même équipe, mais un cas qui s'est bien passé. Le candidat en tant que prestataire d'une grosse ESN arrive avec sa commerciale, peu d'expérience, reconversion plutôt récente dans le développement (alors qu'on cherche un profil plutôt expérimenté) mais quelqu'un de l'équipe de la même boite l'avait déjà vu et avait un bon ressenti. Il n'a pas pu répondre à tout, il a quelques fois dit directement "Je ne sais pas.", d'autres fois "Je crois avoir lu ... sur ça dans ma veille mais pas sûr", la personne prend des notes quand on lui explique des trucs, pose lui-même question parce qu'il est vraiment curieux et intéressé par l'échange. C'était clairement pas l'expert qu'on espérait, c'était clairement pas le gars 100% autonome au 1er jour qu'on espérait, tant pis, on l'a pris dans l'équipe : on a senti que c'était une personne honnête, qui allait progresser super vite, qui s'était construit un socle fort avec de bon réflexe. On aurait pu se tromper comme c'était aussi du ressenti mais ça n'a pas été le cas, c'est devenu assez vite une vraie force dans l'équipe même si oui on l'a accompagné sur certains trucs pour qu'il monte en compétence, et c'est normal. Par contre jamais eu aucun problème d'intégration, de relationnel, ni rien, dès l'entretien, on savait qu'il collait à l'équipe.
Cas inverse que j'ai vécu en tant que candidat cette fois. Fraîchement diplômé, j'ai rejoint une petite ESN en me disant que je voulais pas travailler dans une "usine à code" (j'étais jeune, pardonnez-moi l'expression, j'ai appris à prendre du recul sur tout ça). En tout cas quand on me propose une mission "niveau 2", ou être presta dans une de ces "usines à code" je le sens pas... On m'explique le contexte et en effet c'est ce que je cherche donc je peux pas trop dire non (surtout en inter-contrat et en période d'essai). Je vais à l'entretien sur place, je vois les lieux je vois ce que je veux pas vivre à l'époque (des grands open-spaces, beaucoup trop de gens, etc.), j'essaie clairement de planter l'entretien… La stack annoncé c'est Java/AngularJS, je démonte Java au maximum, vend un langage jeune à l'époque (Go), vend un système de déploiement peu courant pour l'époque (Docker), le tout avec des arguments par contre (bien que certains un peu alambiqués), etc. Et bah vous savez quoi ? J'ai eu la mission, je ne le savais pas (car personne ne s'était vraiment présenté), j'étais face à un nouvel architecte sur le pôle, qui ne travaillait pas sur l'équipe cible, qui m'a trouvé bien parce que j'avais un regard critique mais construit… Par contre la première équipe c'était catastrophique : projet à l'ancienne, les gens ne se parlaient pas, pas de place à la discussion, produire sans poser de question, même sur la stack annoncée, je me sentais en décalage avec l'équipe et je l'ai pas bien vécu du tout. Heureusement ça n'a pas duré longtemps… Mais je suis presque certains que 10min avec le lead de l'équipe pendant l'entretien aurait permis de voir que c'était pas le bon recrutement de me prendre : je n'avais pas assez d'expérience, pas le bon profil, pas le bon mindset.
Communiquez bordel !
La base de la confiance c'est la communication. La première brique qui permet une bonne communication, c'est la confiance. Oups. Vous le sentez le cercle potentiellement vicieux ?
Du coup komenkonfé ?
Simple ! Forcez-vous à communiquer. Je ne vous dis pas de virer au spam, mais vraiment dites les choses "je suis bloqué", "j'ai besoin d'aide", "je ne comprends pas un truc quelqu'un peu m'aider", "je pense que y'a une erreur là parce que…", "j'ai fait… parce que…", etc. Je sais que ce n'est pas naturel pour tout le monde, mais il faut faire ça pour pouvoir travailler en équipe.
Demander de l'aide c'est de la communication. Ça demande un minimum de confiance d'équipe de monter qu'on est faillible, certains y arrivent facilement d'autres non. C'est souvent difficile de demander de l'aide sans confiance d'équipe particulièrement à cause de la peur du jugement. Personnellement je pense qu'on a toujours des choses à apprendre, qu'un pur néophyte peut nous apprendre quelque chose parce qu'il aura lu/vu quelque chose qu'on ne connait pas, donc pas de raison d'avoir des blocages ici.
C'est important pour moi de dire quand on est pas d'accord ou qu'on pense qu'une décision est une erreur. Évidemment, n'arrivez pas en disant "C'est de la merde ! 💩" (même avec l'emoji ça passera pas…). Mais vous pouvez très bien dire "Je ne suis pas d'accord avec ce que tu as dit parce que…", le "parce que" et ce qui suit étant super important ! Pareil vous pouvez dire "Je pense que… c'est une erreur, c'était peut-être ok à une époque mais là je pense pas. Quelqu'un saurait dire pourquoi ce choix a été pris ?".
Dans tous les cas : il faut argumenter !
Ne cherchez pas l'approbation des autres mais une conviction de l'équipe que la décision est la bonne, en évitant autant que possible les arguments d'autorités ("c'est une bonne pratique" si on peut rien expliquer de plus, c'est un argument d'autorité), et évitant les arguments absurdes comme "on a toujours fait comme ça" (le pire argument à mon avis).
Dans le cas où un consensus sur une solution vient vite, n'hésitez pas à jouer l'avocat du diable et trouver des arguments contre la solution pour la challenger. C'est particulièrement utile si la décision est cruciale pour l'avenir du projet.
Il faut aussi rester humble quand on contredit les gens : vous avez peut-être raison, ou peut-être pas. Si vous pensez que les autres peuvent se tromper, vous aussi, et il faut être capable de l'admettre. Vous aussi vous pouvez louper un élément, lâcher une bêtise et on peut vous dire que vous avez tort. Il faut accepter qu'à un moment on va se planter, qu'on va nous expliquer qu'on se plante. C'est humain de se planter et il faut l'accepter, sinon on ne peut pas avancer.
Faites confiance sur le travail produit
Là on arrive à un point qui je sais ne fera pas unanimité : les reviews ça n'est pas nécessaire si on sait se faire confiance dans l'équipe. Je m'explique !
Quand on lance une nouvelle équipe je pense que ça peut être utile, le temps de se roder, de définir le cadre de travail commun. Et après ? Pour moi on peut s'en passer.
Pour moi si l'équipe a un minimum de maturité et de confiance, les gens sauront d'eux-mêmes quand ils ont besoin d'une relecture et la demanderont sous la forme d'un échange avec quelqu'un d'autre. Je trouve qu'une relecture de Merge/Pull Request systématique est une pure perte de temps, ça déresponsabilise les développeurs, ça réduit la qualité du code.
De base je pense que chacun doit être responsable de prendre un ticket et de l'emmener jusqu'en production (ou en environnement de recette si vous n'êtes pas prêt à faire du déploiement continue). Je reste convaincu que chacun est faillible, mais est-ce que c'est si grave d'introduire une petite erreur dans le code si on peut la corriger très vite ? Est-ce qu'on ne peut pas corriger une erreur plus grosse après coup ? Est-ce que l'important c'est pas de délivrer la fonctionnalité ?
On peut même aller jusqu'à basculer en trunk-based (tout le monde commit directement sur la branche principale, sans branche / MR / PR / revue de code). Ça fonctionne bien pour des équipes où les membres se font confiance, avec une bonne communication, si tout le monde à un minimum de maturité. Pour moi l'effet super intéressant c'est qu'on sait que chaque fois qu'on pousse du code, on est obligé de savoir que ça fonctionne correctement, avoir un pipeline de compilation / test / déploiement en béton, ça responsabilise chaque membre de l'équipe, ça réduit le temps pour mettre à disposition en recette (voir production) de nouvelle fonctionnalité, ça incite à faire des petits commits qui font peu de choses (car il n'y a pas de friction à pousser un petit commit, et c'est aussi facile d'annuler si on fait une erreur). Pour moi c'est un incitatif très fort à beaucoup de bonne pratique, à beaucoup de communication, et création de confiance mutuelle.
Conclusion
Comme dit en début d'article, je ne prétends pas détenir la vérité absolue, juste je partage ma vision tirée de mon expérience. Évidemment si je vous le partage c'est que je pense que j'ai trouvé une formule qui fonctionne, maintenant je sais que ce n'est pas toujours simple. On a parfois des contextes avec tellement de contrainte ou tellement d'historique ou même avec des process tellement imprimés profondément qu'on peut difficilement les changer. Mais à minima ça vaut le coup d'essayer de changer des petites choses pour améliorer le quotidien de tout le monde.
Crédit photo : Générée via Mistral AI avec le prompt suivant :
A vibrant retro pixel art illustration inspired by 16-bit RPG games, showing a team of four characters collaborating to defeat a boss labeled 'Bug.' The team consists of a knight labeled 'Dev' with a sword and shield, a rogue labeled 'Tester' with a dagger, a cleric labeled 'Manager' with a healing staff, and a mage labeled 'Designer' casting a spell. The characters are positioned around the boss, emphasizing teamwork. Speech bubbles above their heads contain messages like 'Found it!', 'Let's fix this!', 'I'll review the logs!', and 'Time to optimize!'. The boss is a large, colorful pixelated creature with glowing red eyes. The background features a grassy field with trees and mountains, evoking a classic fantasy RPG setting. The scene is dynamic, colorful, and engaging, reminiscent of games like Chrono Trigger or Secret of Mana.