Travailler dans une équipe informatique
« Travailler dans une équipe informatique » évalue les pratiques collectives : rôles, communication écrite, revue de code, intégration continue et gestion des désaccords. Les questions portent rarement sur la théorie : elles décrivent une situation d'équipe et demandent la réaction professionnelle attendue.
Règles et concepts clés
- Rôles explicites : Product Owner (priorise la valeur), Scrum Master (lève les obstacles, fait respecter le cadre), développeurs, QA. Un rôle flou crée des doublons et des oublis.
- Communication asynchrone et traçable : une décision se prend dans une issue, un ticket ou une pull request, pas seulement à l'oral. Les décisions d'architecture se consignent dans un ADR (Architecture Decision Record) : contexte, options, décision, conséquences.
- Revue de code : objectif = qualité et partage de connaissance. On commente le code, pas la personne ; on explique le problème et on propose une alternative ; on distingue bloquant et suggestion. Les pull requests restent petites, quelques centaines de lignes, pour être réellement relues.
- Conventions partagées : formateur et linter automatisés (hook pre-commit, CI) plutôt que des remarques de style en revue.
- Intégration continue : à chaque push, compilation, tests, analyse statique ; une branche cassée se répare avant tout nouveau développement. Definition of Done explicite : tests, documentation, revue.
- Pair ou mob programming pour diffuser la connaissance et éviter les silos.
- Désaccord technique : tranché par des données (benchmark, POC, test) ou par le Product Owner s'il s'agit d'un arbitrage produit ; jamais par l'ancienneté.
- Feedback : décrire la situation, le comportement observé, l'impact, puis formuler une demande.
Exemple travaillé
Une pull request ajoute un appel SQL dans une boucle for sur 1 000 clients. Commentaire improductif : « ce code est mauvais ». Commentaire utile : « Ici la boucle déclenche 1 000 requêtes (motif N+1) ; sur le jeu de test l'écran met 4 s. Une jointure unique ou un WHERE id IN (...) ramènerait à une seule requête. Peux-tu mesurer après modification ? Sinon on ouvre un ticket de suivi. » On nomme le problème, on chiffre, on propose, on laisse la décision à l'auteur.
Pièges qui coûtent des points
- Revue de code personnelle (« tu as encore oublié ») : elle bloque l'apprentissage et la confiance.
- Commenter en revue ce que le linter corrige automatiquement.
- Pull request géante de 2 000 lignes : personne ne la relit vraiment.
- Confondre vitesse individuelle et débit de l'équipe.
- Escalader un désaccord technique au manager sans aucune donnée.