2. L'ingénierie est un travail collectif de décision

Une bonne équipe technique ne reçoit pas une idée prête à être « transformée en code ». Elle la clarifie avec les personnes concernées, explore les contraintes, construit une première solution, vérifie son effet et apprend de ce qui se passe réellement.

Des rôles différents, une responsabilité partagée

Les intitulés varient d'une organisation à l'autre. On retrouve pourtant plusieurs préoccupations :

Personnes concernées	Préoccupation principale
Produit, métier, utilisateurs	Quel problème vaut la peine d'être résolu ? Quel résultat est utile ?
Design, recherche, accessibilité	Le parcours est-il compréhensible et utilisable par des personnes diverses ?
Développement	Comment rendre ce comportement juste, lisible et modifiable ?
Exploitation, fiabilité, sécurité	Le service peut-il être livré, surveillé, protégé et réparé ?
Support et opérations métier	Que voient les personnes lorsque quelque chose se passe mal ?

Personne ne possède à lui seul toute la réponse. Confier une décision à une personne ne veut pas dire l'isoler : cela veut dire rendre claire la personne qui tranche après avoir consulté celles qui détiennent une information importante.

Une demande est le début d'une conversation

Dire « ajouter un bouton » exprime souvent une solution anticipée, pas le problème. Une équipe peut demander : qui doit réussir quelle action ? dans quels cas cela doit-il être refusé ? quelles données sont concernées ? comment saura-t-on que l'expérience est meilleure ? Ces questions évitent de réaliser rapidement une fonctionnalité qui résout mal le besoin.

Les désaccords ont de la valeur

Un désaccord explicite sur une règle, un coût ou un risque est une information. Il devient dangereux seulement lorsqu'il reste caché jusqu'à la mise en production. Écrire brièvement les options et la raison du choix permet de revoir une décision plus tard, sans reconstruire toute l'histoire.

Pour aller plus loin : responsabilité, modéliser le domaine et leadership technique.