Sur mes mandats de dev, je vois revenir une mode qui sent la maturité: mettre un peu d’ordre dans le TI. On commence à parler de processus, de gestion des incidents, de gestion des changements — des cadres comme ITIL qui veulent sortir les équipes de l’improvisation. Comme développeur, j’ai un sentiment partagé devant ça.

D’un bord, je comprends le besoin. Trop souvent, un changement part en production sur un coup de tête, pis on passe la nuit à éteindre le feu. Trop souvent, un incident est réglé pis personne note rien, fait qu’on recommence la même galère deux mois plus tard. Un peu de discipline, ça peut juste aider.

Le bon réflexe… mal appliqué

flowchart TD
    A[Changement demandé] --> B{Processus léger<br/>ou lourd?}
    B -->|Léger| C[Tracé, approuvé,<br/>on avance]
    B -->|Lourd| D[Formulaires,<br/>comités, attente]
    D --> E[Le monde contourne<br/>pour livrer]
    C --> F[Moins de feux<br/>la nuit]

Mais de l’autre bord, je vois le piège du dev qui veut juste livrer. Si la « discipline » devient une montagne de formulaires pis de comités, le monde va la contourner pour faire la job. Pis là, on retombe dans l’improvisation, mais en cachette. L’ordre qui ralentit tout le monde, c’est pas de l’ordre, c’est de la paperasse.

Ce que ça change pour moi

Comme développeur sur des mandats, ce que je retiens, c’est que le processus doit servir la livraison, pas l’inverse. Tracer un changement, savoir qui a approuvé quoi, garder une trace des incidents — oui, mille fois oui. Mais ça doit rester léger assez pour qu’on l’utilise pour vrai au lieu de le fuir.

Ce que j’en retiens

Mettre un peu d’ordre dans le TI, c’est un signe que le métier mûrit. J’aime l’intention. Je me méfie juste de la version lourde qui transforme la discipline en bureaucratie. Le bon dosage, c’est assez de structure pour dormir la nuit, pas assez pour étouffer le monde qui veut livrer. Pis ce dosage-là, je le vois rarement réussi du premier coup.