L'arrivée de l'agile à OCTO 4/6 : Philippe Kernévez
Cette interview fait partie d’une série, vous trouverez les autres à cet endroit.
Le 28 mars 2018
Philippe Kernévez est arrivé à OCTO début 2000 pour travailler sur l’architecture technique et J2EE. Depuis 2008 il est directeur technique de la filiale suisse d’OCTO.
Te souviens-tu de la manière dont tu voyais l’agile et les agilistes avant qu’ils n’arrivent à OCTO ?
On avait entendu parler de l’eXtreme Programming (XP), certaines personnes avaient des pratiques de développement autour du test automatisé ou de la qualité, mais on ne parlait pas d’agile en tant que tel. Sur la méthode ça se limitait en gros à Scrum.
Qu’est-ce qui a été le plus compliqué au début ?
Certains architectes voyaient l’agile comme de la gestion de projet, loin de la technique, et donc quelque chose qui ne les intéressait pas.
À l’inverse, l’architecture qui consiste à avoir une vision long terme, semblait à l’opposé de l’approche des agilistes – qui était plutôt de dire que la seule chose qui comptait était de faire ce dont on avait besoin pour la semaine.
À ce moment-là il y avait une vraie opposition. Notre point de vue était que les agilistes arrivaient dans une entreprise dont toute l’activité et le développement reposaient sur l’architecture en disant "nous on est les agilistes et l’architecture c’est vraiment un truc inutile". Cela donnait un peu l’impression que, pour eux, l’architecture se limitait à la caricature de l’architecte dans sa tour d’ivoire, qui fait des plans à très long terme qui ne sont absolument pas implémentables.
De notre côté on avait l’impression que les agilistes étaient juste des doux rêveurs qui oubliaient qu’on avait une architecture, des contextes chez nos clients dans lesquels il fallait s’intégrer, et qu’on ne partait pas juste d’une feuille blanche pour faire un petit truc dans son coin.
L’opposition s’est cristallisée sous ces deux appellations : les bleus et les gris et ça a bien pris deux ou trois ans pour commencer à se dépassionner. Nous avons eu des échanges enflammés en interne, avec pas mal de tension dans l’équipe de direction technique qui dépendait de Pierre Pezziardi. Certains débats personnels ont été assez compliqués.
Des personnes comme Marc Cherfi ou Guillaume Duquesnay qui étaient reconnus comme de très bons experts techniques se sont mis à avoir envie de développer d’avantage des valences de coachs. Cela a contribué à briser cette barrière en établissant des ponts entre les deux groupes.
Comment s’est passée l’arrivée de l’agile chez les clients ?
Aujourd’hui l’agile s’applique à l’intégralité de la chaîne depuis métier jusqu’à la production, alors qu’à l’époque le périmètre était beaucoup plus restreint.
On réussissait très peu à impliquer les maîtrises d’ouvrage, quand on parlait d’agile il s’agissait essentiellement d’activité autour du développement comme d’avoir un backlog, ça consistait essentiellement à faire du Scrum.
En 2003-2004 avec Christophe Thibault on avait réussi sur un ou deux projets à embarquer le métier par les tests et à essayer de leur faire-faire du Fitnesse, mais ça restait très anecdotique.
Les conflits internes se passaient sur les mailing-lists et n’étaient pas très visibles chez nos clients : malgré les divergences, les équipes étaient soudées du point de vue humain.
Auriez-vous pu faire quelque chose pour que ça se passe mieux ?
Peut-être qu’on aurait pu éviter certains conflits ou incompréhensions.
Au final c’est le temps et la publication d’une politique pour le SI qui ont permis de faire atterrir une vision partagée et de calmer les choses.
Je ne suis pas certain qu’on aurait pu le faire plus tôt car il fallait avoir une certaine maturité pour l’écrire, et même si on l’avait sortie plus tôt il n’aurait peut-être pas eu les mêmes effets.
Qu’est-ce que l’agile a changé dans ta manière de travailler ?
L’agile a mis de la cohérence sur un certain nombre d’intuitions ou de choses qu’on faisait ponctuellement : on savait qu’on voulait faire des tests automatisés, qu’on avait envie de bosser avec les gens du métier et de déborder sur des aspects de la production…
L’agile m’a donné un discours sur la totalité du process, les étapes à respecter et la manière de mettre une équipe en ordre de marche sur un projet.
Aujourd’hui penses-tu qu’on puisse être architecte SI sans faire d’agile ?
Aujourd’hui, dans beaucoup d’organisations, on peut malheureusement encore faire une belle carrière d’architecte sans faire d’agile. Mais je ne crois pas qu’on puisse être utile en faisant de l’architecture de SI sans intégrer la dimension agile.
Pour moi les architectes devraient être partie prenante des process de développement, et les process de développement devraient être massivement basés sur de l’agile, par conséquent un architecte qui ne fait pas d’agile ça n’a pas de sens.
Après tout ce temps, qu’est-ce que tu n’as toujours pas compris chez les agilistes ?
Le rejet de certaines technologies pour une partie des agilistes. On est d’accord avec eux que certaines technologies, comme Java, ont plein de défauts. Mais ça ne veut pas dire que pour faire de l’agile, il soit nécessaire d’utiliser Ruby on Rails.
Les systèmes de nos clients sont complexes et ont besoin de cohérence, ce qui signifie qu’il y a des règles qu’on peut changer mais d’autres qu’il faut respecter. Changer la méthode de travail sur un système qui a quelques dizaines d’années est déjà une tâche difficile, on ne peut pas changer en même temps l’ensemble des technologies.
Les agilistes qui sont venus à OCTO ont dû apprendre à choisir les messages à passer aux clients : ils sous-estimaient le bruit engendré quand on dit trop de choses.