Deux jours de démarrage en moyenne, contre six auparavant : c’est le chiffre qui ressort le plus nettement du bilan mené deux ans après l’adoption d’un gabarit de projet unique, imposé à l’ensemble de l’équipe pour tout nouveau site WordPress lancé depuis. Ce bilan ne revient pas sur la création du gabarit lui-même, déjà documentée par ailleurs, mais sur ce que son usage prolongé a réellement produit comme effets, positifs et négatifs, sur le fonctionnement quotidien de l’agence.
Trente-et-un projets ont été démarrés avec ce gabarit depuis sa mise en place, un échantillon suffisant pour dégager des tendances fiables plutôt que des impressions isolées.
Le gain de temps mesuré au démarrage
Le temps de démarrage, défini comme le délai entre la première demande client et la première mise en ligne d’un environnement de développement fonctionnel, est passé d’une moyenne de six jours ouvrés à moins de deux jours sur les dix derniers projets lancés. Ce gain provient essentiellement de trois éléments déjà intégrés au gabarit : la configuration des environnements locaux, le pipeline de déploiement de base, et un jeu de conventions de nommage qui évite désormais toute discussion répétée en début de projet.
Ce chiffre masque cependant une réalité plus nuancée : les projets les plus proches du profil type que le gabarit anticipait, un site vitrine ou un site institutionnel classique, bénéficient pleinement de ce gain. Les projets plus atypiques, abordés plus loin, n’en profitent que partiellement.
Ce que la standardisation a coûté en flexibilité
Sur les trente-et-un projets recensés, quatre ont nécessité un écart significatif par rapport au gabarit standard, pour des besoins que celui-ci ne couvrait pas nativement : une intégration poussée avec un système de caisse physique, une architecture headless complète, et deux projets à forte volumétrie nécessitant une configuration de cache spécifique dès le départ. Sur ces quatre projets, le temps gagné au démarrage a été partiellement reperdu à devoir défaire certaines conventions du gabarit plutôt qu’à simplement les compléter.
| Type de projet | Nombre | Temps de démarrage moyen |
|---|---|---|
| Profil standard, conforme au gabarit | 27 | 1,8 jour |
| Profil atypique, écarts nécessaires | 4 | 4,2 jours |
Ce tableau illustre une limite structurelle de tout gabarit unique : il optimise fortement le cas majoritaire, au prix d’une friction accrue sur les cas qui s’en écartent, une friction qui aurait été moindre sans gabarit imposé du tout, chaque projet démarrant alors de zéro selon ses besoins propres.
Un effet secondaire non anticipé : la formation des nouvelles recrues
Un bénéfice inattendu concerne l’intégration des nouvelles personnes dans l’équipe. Une conception unique et documentée signifie qu’une personne formée sur un projet comprend immédiatement la structure de tous les autres projets standards de l’agence, sans devoir réapprendre des conventions différentes à chaque changement de dossier. Ce gain, difficile à chiffrer précisément, ressort clairement des retours qualitatifs recueillis auprès des trois dernières personnes recrutées.
Ce qui a demandé une révision au fil des deux ans
- La version de PHP ciblée par défaut, relevée deux fois en deux ans pour suivre les évolutions du langage
- L’outil de build front, remplacé une fois sans que cela n’affecte les projets déjà lancés avec l’ancien
- Les conventions de nommage des branches Git, ajustées après un premier retour d’expérience collectif
Un gabarit figé au moment de sa création aurait fini par accumuler du retard technique sur ces trois points. La révision annuelle programmée, plutôt qu’une réécriture ponctuelle sans cadence définie, a permis d’absorber ces évolutions sans jamais casser la compatibilité des projets déjà en cours.
Notre verdict
Deux ans après sa mise en place, le gabarit unique a tenu ses promesses sur les projets qui correspondent à son profil cible, avec un gain de temps mesurable et une intégration facilitée des nouvelles recrues. Son revers, une rigidité réelle sur les projets atypiques, reste un compromis assumé plutôt qu’un défaut à corriger : un gabarit qui tenterait de couvrir tous les cas de figure perdrait précisément ce qui fait sa valeur, la rapidité de démarrage sur le cas le plus fréquent.
