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.

Me contacter sur LinkedIn