Les raisons sont nombreuses et se combinent à l’infini, ou presque :
- les grands-comptes s’appuient sur des identités fortes construites sur des marchés toujours différents (produits, réseaux de distribution, identité de marque, cibles, etc.) ;
- l’historique informatique implique des contraintes culturelles et techniques toujours spécifiques, même si les tendances stratégiques sont partagées ;
- la maturité digitale est plus variable que ce que l’on veut bien afficher ;
- l’attractivité de l’entreprise et de son secteur impacte fortement les profils techniques qui acceptent d’intervenir : ce qui structure le type de logiciels qui sont produits, et qui doivent ensuite être connectés ;
- le lead budgétaire du projet se ressent dans la distribution des moyens entre les équipes (métier, fonctionnel et technique) du projet à court comme à long termes ;
- la qualité des projets est plus ou moins homogène au sein d’une même stack et toujours hétérogène d’une stack à l’autre : cela vaut autant pour le pilotage, pour la mise en œuvre que pour la maintenance ;
- les équipes qui construisent ne sont jamais celles qui maintiennent, et leurs goûts pour la complexité est sensiblement différentes : les équipes build recherchent les défis à relever et le renouvellement, les équipes run ont pour priorité la stabilité à long terme ;
- la qualité des livrables de conception est toujours hétérogène, parfois inexistante ;
- les livrables de documentation fournis par les équipes build sont le plus souvent inexistants, et rarement au niveau nécessaire pour le bon maintien en conditions opérationnelles par les équipes run ;
- les budgets de reprise pour le run sont le plus souvent tirés à la baisse pour des raisons de mise en concurrence : il est rare que les moyens nécessaires soient mis à disposition pour auditer le risque, identifier les priorités et construire la documentation technique qui a été… dépriorisée par l’équipe build ;
- concernant plus spécifiquement Drupal : même si la situation progresse depuis la version 8 (notamment au niveau de la construction du code avec composer) son industrialisation reste complexe, et parfois fragile ;
- chaque DSI a sa vision de l’industrialisation, et le projet Drupal doit être adapté pour s’insérer dans ces dispositifs depuis la construction du code, et sa vectorisation, jusqu’à la prise en compte des politiques de sécurité, la boite à outils du déploiement, les pratiques de gestion des versions et les processus de validation par environnement ;
- et à la vitesse du digital, un projet de grand compte qui nécessite en moyenne entre 12 et 18 mois de sa conception à sa livraison… n’est jamais à la dernière mode au moment de sa mise en service – et si cela devait constituer une des contraintes du projet (ce qui est techniquement réalisable), cela en ferait un exemplaire plutôt atypique.
Oui, tout projet de grand compte est nécessairement, invariablement, mécaniquement : vraiment unique.
Dans cette newsletter, je vous propose de partager mon expérience Drupal acquise sur plusieurs dizaines de projets de grands comptes depuis une quinzaine d’années : pour mettre en lumière les risques évitables, et présenter des stratégies de contournement qui permettent d’anticiper les situations coûteuses ou, si le mal est déjà fait, de mettre en place un plan d’actions pour sécuriser et réparer.