La surrépartition des tâches

Publié le 25 avril 2025

On a tendance à trop diviser les tâches et à les répartir. Je pense que ça touche tous les domaines mais je vais parler du milieu de la tech parce que c'est celui que je connais. Mais je ne pense pas me tromper si je dis que c'est pareil dans le milieu du bâtiment.

On surrépartit de deux façons différentes.

La première est par équipe : l'équipe front, l'équipe back, les PO & scrum master, l'équipe design, les architectes, l'équipe infra & devops et pour finir les chefs ou la direction. Il y a rarement toutes ces équipes dans une entreprise mais je pense que vous avez au moins 5 de ces 7 équipes dans votre entreprise.

La seconde surrépartition concerne la division extrême des tâches. Par exemple pour créer une page listant des factures, il va y avoir la partie front avec le développement du tableau pour lister les factures et les appels API, la partie backend pour créer l'endpoint et la gestion du download avec les permissions et pour finir, la partie infra pour le stockage de fichier sur AWS ou autre.

Si je devais faire un lien avec le bâtiment, pour la construction d'une extension à notre maison, on aurait : un architecte, un maçon, un peintre, un mec pour poser le placo et le parquet, un électricien, un mec pour la charpente et un plombier parce que pour l'agrandissement on touche aux canalisations. 7 personnes différentes avec des compétences différentes pour construire une pièce supplémentaire. Je ne suis pas du métier, mais ça me paraît overkill.

Plus personne n'est responsable de rien

Chacun fait sa petite partie. Il faut qu'elle soit bien faite et le reste importe peu. C'est comme cela que l'on juge de la compétence de l'individu. Le dev front s'occupe de faire son tableau et les appels API vers le backend. Le dev back s'occupe de créer les API pour lister et télécharger les factures ainsi que de faire les appels au serveur de fichiers pour récupérer les factures. L'infra s'occupe de mettre en place le serveur de fichiers et de configurer les accès pour que le backend puisse y accéder et que tout le monde puisse communiquer entre eux.

Ça ne marche pas ?

• Le dev front regarde la devtool, il n'y a aucun problème détecté, les appels API sont bien faits — ça doit être la faute du backend.
• Le dev back regarde les logs serveurs, il n'y a pas d'erreur 500, rien d'anormal — ça doit être la faute de l'infra.
• Le dev infra regarde ses serveurs, les dockers sont bien lancés, les fichiers sont disponibles, il n'y a pas de problème non plus — ça doit être la faute d'une mauvaise coordination entre le front et le backend.
• Et si ce n'était pas à cause du PO ? Peut-être que les specs n'étaient pas assez claires.

Ce n'est jamais la faute de personne. Personne n'est responsable.

Si l'on détecte une erreur dans la devtool, c'est la faute de qui ? - Est-ce que c'est le front qui a mal configuré ses variables d'environnement ? - Est-ce que c'est le front qui ne transmet pas le bon payload ? - Est-ce que c'est le front qui ne tape pas sur le bon endpoint ? - Est-ce que c'est le backend qui ne répond pas ? - Est-ce que c'est le backend qui a mal configuré son env ? - Est-ce que c'est un bug côté backend ? - L'infra ne se mélange-t-elle pas les pinceaux entre tous les env ? prod, pre-prod, staging, demo, dev, test, etc. - Est-ce que l'infra a bien configuré le nginx ? - Est-ce que l'on n'a pas release une version du front-end incompatible avec le backend ?

Pourtant tout a été codé aux petits oignons. Le dev front fait une belle architecture hexagonale. Il a écrit des tests avec Cypress pour avoir des tests "réels" pour vérifier que tout fonctionne. Le dev backend écrit des tests unitaires et des tests fonctionnels pour tester chaque endpoint dans les moindres recoins avec les cas les plus tordus possibles. Aucune erreur n'est possible ! Le dev infra a tout automatisé via de super scripts Ansible et toutes les dernières technos à la mode : Terraform, Kubernetes, Helm, etc.

Pourquoi malgré tout cela, ça ne marche pas ? Qui est responsable ? Faut-il autant d'équipes différentes pour afficher une liste de factures et les télécharger ?

Plus personne ne comprends rien

L'application est tellement complexe que chaque développeur est spécialisé dans son domaine. Il améliore sa partie, mais s'éloigne des autres — les comprenant encore moins.

• Le dev front n'est responsable que de son tableau et de son appel API.
• Le dev back n'est responsable que du développement de son API.
• Le dev infra n'est responsable que de la configuration de l'infrastructure.

Chaque équipe se retrouve avec beaucoup de temps pour accomplir au final qu'une toute petite tâche. Alors on "s'applique". On fait les choses "bien" et "proprement". On perd juste énormément de temps.

Pendant que certains développeurs doute de l'utilité des tests et décident même de les supprimer, nos équipes ont beaucoup de temps libre. Alors elles mettent en place des architectures complexes, des pipelines dans tous les sens, des tests partout.

Tout devient extrêmement complexe, et nécessite beaucoup d'expérience et de rigueur pour être maintenu. Mais le code est propre !

C'est devenu tellement complexe que plus personne ne maitrise de bout en bout la page pour liste et télécharger des factures. Personne ne sait vraiment comment cela fonctionne.

Il est important de répartir les tâches et de se spécialiser. Personne ne peut tout savoir faire. Et personne au monde ne sait fabriquer un simple crayon à papier! Mais quand il s'agit de chercher dans un classeur pour retrouver une facture (ou tout autre tâche équivalente), je ne pense pas qu'il y est besoin d'autant d'experts.

Que se passe-t-il si le dev back est en congé et qu'il y a un bug sur le format du payload retourné ? C'est trop complexe et le dev front ne peut pas le modifier. Il faut avoir les droits sur le repo, trouver l'endroit dans le code où le payload est construit, le corriger, modifier les tests pour prendre en compte ce bug, créer une pull request, la faire valider par un autre développeur compétent, déployer la modification sur un serveur de test, et vérifier que désormais tout fonctionne correctement.

Il y a tellement de process à suivre, tellement de complexité — plus personne ne comprend rien — qu'une simple correction de ce type prend au minimum une demi-journée au lieu des 5 minutes que cela devrait prendre.

Ça ne marche jamais

Avez-vous déjà observé comment sont développés les projets qui fonctionnent ? Ces fameux projets "legacy". Ceux qui rapportent de l'argent à votre entreprise, ceux qui permettent de vous payer un salaire ?

On adore les critiquer ces projets legacy. Mais ils ont tous un point commun entre eux.

Il n'y a pas 10 000 développeurs à travailler sur ces projets. Le ou les (c'est rarement plus de 3) devs travaillent sur toute la partie du projet. Il n'y a pas de spécialisation ou de répartition par équipe. Tout le monde est responsable. Il n'y a JAMAIS de tests unitaires, il n'y a pas dix environnements de prod/pre-prod/staging/tests ou autres, pas d'architecture SOLID, pas de TDD, pas de microservices, pas de CI et pour finir pas de kubernetes.

On nous apprend que c'est absolument TOUT CE QU'IL NE FAUT PAS FAIRE. Pourtant le projet fonctionne suffisamment bien pour que des clients dépensent de l'argent pour l'utiliser. Étrange, non ?

Bien sûr que rien n'est parfait, et qu'il y a plein de problèmes sur le projet. Mais c'est ce qui paie votre salaire, pas la pipeline avec SonarQube.

Inversement, connaissez-vous un projet successful avec kubernetes ?

Connaissez-vous un projet en microservices qui fonctionne ? Ou un projet avec des tests fonctionnels dans tous les sens ?

En 10 ans de carrière, je n'ai jamais vu cela fonctionner et je ne connais personne dont c'est le cas. Alors bien sûr, il doit bien y avoir l'exception à la règle. Mais c'est l'exception — pas le cas courant.

The simpler the solution, the more likely it is to work.