Ce que le processus vous apporte réellement

La plupart des résistances au processus viennent de l'expérience d'un mauvais processus. Les ingénieurs qui ont assisté à des réunions de statut de deux heures, rempli des formulaires de demande de changement pour une correction d'une ligne, ou regardé un consultant en « transformation » réorganiser l'organigramme ont toutes les raisons de tressaillir quand quelqu'un dit « nous avons besoin de plus de processus ».

Ce tressaillement est rationnel. Le mauvais processus est réel, il est courant, et il gaspille énormément de temps. Mais la conclusion que la plupart des équipes tirent — « le processus lui-même est le problème » — ne suit pas. Une équipe qui a eu un mauvais repas ne renonce pas à la nourriture. Elle trouve un meilleur restaurant.

Le recadrage est simple : le processus n'est pas les règles que quelqu'un d'autre impose à votre travail. Le processus est tout modèle répétable qui rend la prochaine fois plus facile que la dernière fois. Une convention de nommage pour les branches est un processus. Une liste de vérification partagée avant de fusionner une PR est un processus. Une mêlée quotidienne de cinq minutes où trois personnes se synchronisent sur les blocages est un processus. Aucun de ceux-ci ne nécessite de certification ou de consultant. Tous se composent.

Les équipes qui disent « nous n'avons pas besoin de processus » ont presque toujours un processus — il est juste implicite, non documenté, et vit dans la tête d'une personne. Cela fonctionne jusqu'à ce que cette personne soit en vacances, quitte l'entreprise, ou rejoigne un deuxième projet. Ensuite, l'équipe découvre qu'elle avait un point de défaillance unique, pas une culture sans processus.

Chaque élément de processus crée soit un levier, soit une surcharge. Le test est simple : cette pratique rend-elle la prochaine unité de travail moins chère, plus rapide ou plus sûre que la dernière ?

Une liste de vérification de révision de code est un levier — elle détecte la même classe de bogue à chaque sprint sans exiger que le réviseur se souvienne de tout à partir de zéro. Un comité d'examen d'architecture obligatoire qui se réunit toutes les deux semaines et met les changements en file d'attente pendant 10 jours est une surcharge — il ralentit la livraison sans réduction proportionnelle du risque.

La distinction ne concerne pas la formalité. Les processus formels peuvent être à fort levier (les règles de protection de branche qui empêchent les force-push vers main ne coûtent rien une fois configurées et préviennent les erreurs catastrophiques indéfiniment). Les processus informels peuvent être de la pure surcharge (la règle non écrite selon laquelle « vous devriez en parler à Dave avant de fusionner » parce que Dave a été brûlé une fois par un mauvais déploiement et maintenant personne ne sait si l'approbation de Dave est requise ou culturelle).

Trois signaux qu'un élément de processus est passé du levier à la surcharge :

• Les gens le contournent. Si les ingénieurs sautent régulièrement une étape parce qu'il est plus facile de demander pardon, l'étape ne fournit pas assez de valeur pour justifier sa friction.
• Personne ne peut expliquer pourquoi il existe. Si la réponse à « pourquoi faisons-nous cela ? » est « nous l'avons toujours fait », le processus a survécu à sa justification.
• Il évolue avec l'effectif, pas avec le risque. Un bon processus évolue de manière sous-linéaire — un pipeline CI sert 50 ingénieurs. Un mauvais processus évolue linéairement — chaque nouvelle embauche ajoute une autre ligne à la matrice d'approbation.

Quand vous trouvez une surcharge, supprimez-la. Quand vous trouvez un levier, documentez-le pour qu'il survive aux changements de personnel.

Quelle que soit la taille de l'équipe, le domaine ou la préférence méthodologique, trois capacités sont non négociables :

• Contrôle de source. Chaque ligne de code est versionnée, attribuée et récupérable. Ce n'est pas controversé en 2026 — mais « nous utilisons Git » et « nous utilisons bien Git » sont des déclarations différentes. Le Module 2 couvre la différence.
• Suivi du travail. Chaque élément de travail en cours est visible pour toute l'équipe dans un système partagé — pas dans une feuille de calcul, pas dans la tête de quelqu'un, pas dans un fil Slack qui défilera hors de l'écran d'ici mardi. Les tickets sont l'unité de suivi du travail, et le Module 3 couvre ce qui fait un bon ticket.
• Communication d'intention. L'équipe a un mécanisme régulier et léger pour partager ce sur quoi elle travaille, ce qui la bloque, et ce dont elle a besoin les uns des autres. Cela peut être une mêlée quotidienne de cinq minutes, une publication asynchrone dans un canal, ou un tableau partagé — le format importe moins que la cohérence.

Tout le reste — sprints, story points, rétrospectives, limites WIP, graphiques de vélocité — est de la méthodologie. La méthodologie est précieuse, mais c'est la couche au-dessus de ces bases. Vous pouvez exécuter Scrum sans tableaux Kanban. Vous pouvez exécuter Kanban sans story points. Vous ne pouvez exécuter ni l'un ni l'autre sans contrôle de source, suivi du travail et communication d'intention.

Le reste de ce cours se concentre sur ces trois fondamentaux. Le Module 5 vous aidera à décider s'il faut superposer une méthodologie par-dessus — et si oui, laquelle.