La gouvernance technique désigne l'ensemble des processus, règles et pratiques qui encadrent les décisions technologiques au sein d'une organisation. Elle définit qui décide, comment et selon quels critères les choix techniques sont faits et suivis dans le temps.
Le Risque de l'Anarchie
Sans gouvernance, les décisions prises au fil de l'eau créent une accumulation de technologies hétérogènes. Le résultat : une dette technique croissante et une perte de maîtrise progressive du système d'information.
Mise en Œuvre Légère
Pour une PME, il s'agit de définir des principes directeurs (technologies, standards de qualité), de documenter les décisions et de réviser régulièrement les choix en fonction de l'évolution du marché et des besoins réels.
Ce que la gouvernance doit trancher
Dans une PME ou une startup, la gouvernance technique n'a pas besoin de comité. Elle doit simplement apporter une réponse claire à quelques questions, et que cette réponse soit écrite quelque part :
- Qui possède quoi — le dépôt de code, l'hébergement, les noms de domaine, les comptes de services tiers. Ils doivent appartenir à l'entreprise, pas à un salarié ou à un prestataire.
- Avec quoi on construit — un socle technique commun, et un critère pour accepter une nouvelle technologie.
- Comment le code arrive en production — revue, tests, pipeline de déploiement, qui peut valider.
- Comment on décide — qui arbitre entre une fonctionnalité et la dette, comment une décision d'architecture est consignée.
- Comment on surveille — qui est alerté quand la production ou une sauvegarde échoue.
Comment je la mets en place
Je préfère des règles peu nombreuses, outillées et vérifiées automatiquement, à un document de référence que personne ne relit :
- Des conventions appliquées par la CI — analyse statique, style de code, tests : une règle que la machine vérifie n'a pas besoin d'être rappelée en réunion.
- Des décisions d'architecture écrites au moment où elles sont prises, avec le contexte et les alternatives écartées.
- Un changement par commit, et ce qui touche un contrat — une API, un format de données — isolé et relu pour lui-même.
- Une règle de trois pour mutualiser — un besoin rencontré une fois reste dans son projet ; trois fois, on l'extrait. On évite ainsi les abstractions prématurées comme le copier-coller qui diverge.
Un exemple concret
Les cinq applications que je maintiens pour Orange reposent sur les mêmes fondations : Symfony, API Platform, MySQL, Docker. Ce n'est pas un hasard, c'est une décision de gouvernance. Une image Docker de base commune fixe le système, la configuration PHP et la chaîne de déploiement ; une librairie PHP partagée porte les composants transverses, avec une règle stricte : le code métier n'y entre jamais. Le résultat est mesurable : quand une version de PHP approche, l'étude de compatibilité porte sur un socle connu, et une correction faite une fois profite à toutes les applications.
En reprise d'application, la gouvernance est souvent ce qui manquait le plus : des accès dispersés, un déploiement connu d'une seule personne, aucune règle de relecture. La remettre en place fait partie des premières étapes, avant toute évolution.
Les pièges
- La gouvernance-bureaucratie — un comité d'architecture qui valide chaque choix ralentit tout et finit contourné.
- La gouvernance déléguée au prestataire sans contrôle : c'est lui qui décide, et l'entreprise découvre les conséquences au moment d'en changer.
- Des règles sans outil : une convention que rien ne vérifie se dégrade à chaque arrivée dans l'équipe.
La gouvernance technique n'est pas une bureaucratie pesante, c'est la boussole qui assure que chaque choix technologique sert durablement la stratégie business de l'entreprise.
Remettre en place une gouvernance claire — accès, dépôt, déploiement, sauvegardes — fait partie de ma prestation de reprise d'application web. Quand il manque surtout une direction technique, voir CTO externalisé : quand et pourquoi y recourir.