Expertise Drupal 8 / 9

Seul le projet compte.

Malgré la qualité du travail communautaire du socle du projet Drupal Core, et de la richesse des propositions de valeur des Modules contribués, le cycle de vie logiciel des projets Drupal ne fait pas exception : plus de complexité apporte plus de risque.

Risques projet

Ainsi, les évènements suivants ne manquent pas d’apparaître à mesure que le temps passe, parfois même, dès la phase de construction du projet :

  • la liste des modules activés s’allonge ;
  • la gestion des mises à niveau de sécurité doit rester régulière ;
  • le poids du code spécifique grandit, et la dette technique s’accumule ;
  • les outils de construction et de déploiement de code se fragilisent ;
  • les équipes évoluent ;
  • la connaissance se dillue ;
  • les coûts augmentent ;
  • les API-dépendances du projet changent ;
  • les données à importer évoluent, et les scripts de migration se fragilisent…

Le spécifique, c’est de la dette

Le coût annuel de TMA d’un projet est estimé entre 10% et 15% du coût initial de réalisation… quand le travail répond aux standards de qualité attendus.

Souvent se recouvrent plusieurs dimensions qui s’aggravent l’une-l’autre :

  • trop de complexité
  • trop de code spécifique
  • peu de documentation, pas d’anticipation de la réversibilité
  • un niveau de séniorité nécessaire trop élevé : à la rareté des profils disponibles, leur prix élevé, s’ajoute leur peu d’enthousiasme pour s’investir dans la maintenance de projets mal réalisés par d’autres…

En d’autres termes, même avec une sécurité maîtrisée, du code stable, une performance et une scalabilité satisfaisantes : le surcoût de maintenance (code, conception) rencontrera le risque marché (profils).

Limiter les frictions, abaisser la séniorité

Pour répondre à ces problématiques, la première phase est nécessairement l’Audit. Une fois l’état des lieux réalisés, et les préconisations hiérarchisées, il est rarement tenable de lancer un nouveau lot sans un chantier intermédiaire :

  • corriger, réparer ;
  • ré-aligner tous les environnements de manière durable ;
  • mettre à jour les documentations (dont le code) ;
  • restructurer tout ce qui permet d’abaisser le périmètre de séniorité élevé ;
  • limiter les frictions et les dépendances avec les autres outils, et avec les autres équipes ;
  • démonter toute la complexité qui apporte une valeur métier faible ;
  • unifier les approches, limiter le code, simplifier tout ce qui peut l’être.

Tout est adressable

Tout ce qui est embêtant, n’est jamais valorisé lorsque le travail a été fait, mais est violemment ressenti lorsque l’on en a fait l’économie :

  • industrialisation, déploiement continue
  • standards de codage
  • conceptions drupaliennes diverses : générisation du code, un dépôt par module, etc.
  • pilotage intégral de la construction par composer
  • alignement des EDI de développement : paramétrages, plugins, etc.
  • alignement des environnements de développement
  • qualité des cérémonies agiles : écoute réciproque, responsabilisation partagée, vision convergente
  • capacité des équipes Métier et Technique à se comprendre

Comme le Scrum Master qui a réussi lorsque son équipe n’a plus besoin de lui, un projet Drupal nécessitant moins de séniorité et d’expertise élevée est un projet qui…

  • pourra être maintenu plus longtemps en conditions opérationnelles,
  • pour un volume de charge plus bas,
  • par une équipe moins coûteuse.