Vraiment unique
Quand bien même l’expression de besoin serait identique : d’un grand compte à l’autre, on ne refait jamais le même projet Drupal.
 |
Les raisons sont nombreuses et se combinent à l’infini, ou presque.
Partage des marchés
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.
Historique informatique
Comme chacun sait, toutes les DSI des grands comptes reçoivent les mêmes études de tendances stratégiques. Et l’évolution de ces tendances démontrent que celles-ci sont effectivement mises en œuvre au fil du temps.
Pour autant, l’historique informatique de chaque entreprise fabrique en interne des contraintes culturelles au sein des équipes :
méthodologies privilégiées,
politique de sécurité,
culture du management
Mais aussi des spécificités techniques qui constituent un socle qui influence directement les coûts de production, et donc les arbitrages opérés pour un nouveau projet.
Image de marque digitale
La maturité digitale elle-même est plus variable que ce que l’on veut bien afficher. Il y a très souvent un écart entre :
la maturité affichée qui correspond le plus souvent à la moyenne de l’entreprise
ou à celle du locuteur
et la réalité des équipes effectivement embarquées. Parmi celles-ci, il faudra encore distinguer :
les parties prenantes, et
les opérationnels
L’attractivité
L’attractivité de l’entreprise et de son secteur impacte fortement les profils techniques qui acceptent d’intervenir.
Ceci structure directement les types de logiciels qui sont produits, et qui doivent ensuite être connectés au projet.
Lead budgétaire
Le lead budgétaire du projet se ressent dans la distribution des moyens entre les équipes du projet :
métier,
fonctionnel, et
technique
Et décide de la construction du projet à court terme (Build), comme de son évolution à long terme (Run).
Qualité
Chez un acteur donné, en fonction du niveau de partage des pratiques au sein des équipes, la qualité des projets est plus ou moins homogène au sein d’une même stack.
Ce qui définit le niveau de qualité de référence est différent
d’une stack à l’autre,
d’une communauté de développeur à une autre
Cela vaut autant
pour le pilotage,
pour la mise en œuvre que
pour la maintenance
Dans une informatique digitale qui voit naître de plus en plus de projets multi-stacks, cela accélère les besoin de convergence des pratiques pour délivrer un niveau de qualité similaire.
Mais les rythmes d’adoption et de diffusion des pratiques favorisent ces disparités.
Build vs Run
Les équipes qui construisent ne sont jamais celles qui maintiennent.
Leurs goûts pour la complexité sont sensiblement différents :
les équipes build recherchent les défis à relever et le renouvellement,
les équipes run ont pour priorité la stabilité à long terme
Stabilité des livrables
Généralement, l’applicatif qui constitue le livrable principal fonctionne comme attendu. Mais cela ne donne d’information que sur la stabilité à la date de Mise en service du projet.
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.
C’est la qualité de ces livrables qui informe sur ce qui adviendra des investissements réalisés à moyen et long terme.
Risques propres au 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
Autrement dit, la préparation de la passation entre les équipes Build et Run constitue l’étape clé dans la gestion du risque. C’est le maillon faible du cycle de vie applicatif et de sa rentabilité.
Industrialisation de Drupal
Concernant plus spécifiquement Drupal, la situation progresse depuis la version 8
au niveau de la construction du code avec composer,
au niveau de la construction des environnements avec docker
Pour autant, son industrialisation reste complexe, et parfois fragile car il nécessite un Lead Tech ou un CTO maîtrisant
cette partie DevOps aussi bien que
l’architecture Drupal qui reste le cœur de sa mission
Chaque DSI a sa vision de l’industrialisation qui s’impose aux projets
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
Il ne s’agit donc pas pour le Lead Tech de faire du DevOps à la sauce Drupal, mais bien de mettre son expertise Drupal au service des équipes DevOps en place.
Sa capacité à échanger avec pédagogie auprès des équipes Ops est critique.
Innovation digitale ?
À 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.
Si cela devait constituer une des contraintes du projet (ce qui est techniquement réalisable), cela en ferait un exemplaire plutôt atypique.
Un projet Grand Compte est toujours unique
Oui, tout projet de grand compte est nécessairement, invariablement, mécaniquement : vraiment unique.
C’est ce que j’ai appris à réaliser des projets Drupal depuis une quinzaine d’années
au fil des versions et des migrations
à refaire parfois le “même” projet : site de musée (Louvre vs Musée de l’Orangerie), site de transport (Transilien vs RATP), etc.
à recentrer les coûts de fabrication sur le cœur de valeur Business
Il y a aussi des tendances et des pratiques consolidées que je retrouve lors de mes audits :
l’utilisation des méthodes agiles,
des architectures plus modulaires, moins monolithiques,
un poids plus élevé de l’accessibilité et du SEO, et
une part plus importante de la place des APIs ouvertes
Si cette expérience partagée vous a interpellé.e, n’hésitez pas à me contacter : je serai heureux de rejoindre votre équipe pour participer activement à livrer votre nouveau projet.