Je m’apprête à devenir Product Owner en environnement bancaire, côté webmastering. Sur Drupal. Et autant vous dire que ça occupe mes soirées de veille technique en ce moment.
Première réaction, sincèrement : un peu de sueur froide anticipée. Après des années à bidouiller du WordPress sur Pixevent, avec SiteGround qui m’envoie des plugins IA sans demander mon avis, je vais débarquer dans un monde où chaque ligne de config a l’air de peser trois tonnes. Le café du matin va sûrement avoir un goût différent le jour où je saurai que derrière mon écran, il y a des données bancaires de vrais gens.
WordPress, c’est mon garage. Drupal, c’est l’usine
Je vais pas vous mentir. WordPress, j’adore. C’est mon terrain de jeu perso, ma bagnole de garage que je répare le soir avec une Coca Zero à côté du clavier. Ça bricole vite, ça se déploie vite, ça pardonne les erreurs.
Une banque, elle, ne pardonne rien. Zéro faille tolérée. Zéro round de « on verra plus tard pour la sécu ».
Et c’est là que Drupal change de statut. Ce CMS que beaucoup trouvent lourd, austère, presque ringard face à la fluidité de WordPress, devient soudain une évidence.
Pourquoi les banques aiment Drupal
Pas par nostalgie. Par calcul.
D’abord, la gestion des permissions. Dans Drupal, tu peux découper les rôles utilisateurs avec une précision chirurgicale. Qui peut publier, qui peut juste relire, qui peut toucher au code. En environnement bancaire, ce niveau de granularité n’est pas un luxe, c’est une exigence réglementaire.
Ensuite, le cycle de sécurité. L’équipe de sécurité Drupal traite les vulnérabilités avec une rigueur presque militaire. Des annonces coordonnées, des patchs qui sortent en musique, un historique public consultable. Face à ça, l’écosystème des plugins WordPress fait parfois un peu penser à un marché aux puces où n’importe qui vend n’importe quoi.
Troisième point, moins technique mais tout aussi important : l’auditabilité. Un auditeur qui débarque avec sa checklist de conformité préfère largement une architecture Drupal bien structurée à une usine à gaz de plugins WordPress empilés au fil des années par trois développeurs qui ne se sont jamais parlé.
Le vrai coût, c’est ailleurs
Alors non, Drupal n’est pas magique. La courbe d’apprentissage est raide. Franchement raide. Rien qu’en lisant la doc ces derniers jours, j’ai eu l’impression de réapprendre à faire du vélo avec des skis aux pieds.
Mais le vrai coût d’un CMS, ce n’est jamais le prix d’entrée. C’est ce qui se passe après, quand ça part en vrille. Un incident de sécurité sur une plateforme bancaire, ça ne fait pas juste mal à l’ego du Product Owner. Ça fait la une, ça déclenche des audits, ça coûte une fortune en réputation.
Drupal encaisse mieux ce genre de scénario. Pas parce qu’il est parfait, mais parce que toute son architecture a été pensée pour des environnements où l’erreur coûte cher.
Ce que ça va changer pour moi
Je vais passer d’un monde où je suis seul aux commandes, où je décide, je code, je publie, à un monde où chaque décision technique s’inscrira dans un cadre. Sprints, specs, validations à plusieurs niveaux. Le rythme va changer. La verveine du soir aussi, probablement, parce que les horaires vont bouger un peu.
Mais il y a un truc que je m’attends à retrouver, presque identique. Cette sensation d’apprendre en marchant. Comme quand j’ai débarqué à Vancouver en 2018 pour faire de l’immobilier commercial sans connaître les codes locaux. Tu observes, tu poses des questions bêtes, tu finis par piger le système.
Drupal, bientôt, ce sera un peu ça pour moi. Un nouveau système à décoder. Et pour un futur Product Owner qui aime comprendre pourquoi les choses sont faites comme elles sont faites, plutôt que de juste les subir, ça s’annonce plutôt stimulant.