Compte rendu : La duck conf 2020

L’an dernier, nous n’avions pas réussi à avoir de speakeuse et je m’en étais excusé.

Cette année, il n’y avait pas non plus de speakeuse, mais le sujet n’a pas été abordé, et le code de conduite n’a pas été mentionné. Si vous ajoutez les slides presque uniquement au masculin, j’ai été très désagréablement surpris qu’Octo s’inscrive à rebours de ce qui se fait dans la plupart des autres évènements.

Je ne sais pas comme le dire avec des pincettes : un certain nombre de talks manquaient de finition.

Pas de plan annoncé, déroulé pas clair, nombreuses redites… dans plusieurs cas, je me suis retrouvé à lutter pour suivre le fil de ce qui était dit, alors que le contenu était là.

C’était assez rageant car j’avais le sentiment que 90% du travail avait été fait mais que les 10% manquants auraient pu faire une vraie différence.

J’aurais aussi aimé des talks un peu plus ciblés sur l’architecture et des retours d’expériences un peu plus exotiques.

Sur le sujet du cloud, Kubernetes a régné en maître quasi-absolu. Cela tranche beaucoup avec l’état du marché, ou même le panorama discuté à la conférence l’an dernier (PaaS, lambda…).

C’est une conséquence directe du fait qu’Octo vend de l’expertise Kubernetes, et que les personnes font des talks sur les sujets qu’ils connaissent, mais quand même.

Ce qui m’a le plus gêné, c’est l’absence de recul sur la complexité que Kubernetes impose aux équipes de développement : quand j’entends dire plusieurs fois qu’il faut avoir un ops, au moins à temps partiel, par équipe de développement pour gérer les fichiers de déploiements pour des applications standards et que tout le monde a l’air de trouver ça normal, j’ai un peu l’impression d’être un extra-terrestre. Qu’une expertise particulière soit nécessaire pour remplir les fichiers de configuration d’une application standard, c’est une faiblesse patente de l’offre (ou de l’approche) Kubernetes, et je comprends très bien que des entreprises redéveloppent des outils spécifiques, même s’ils ne donnent pas forcément satisfaction, pour éviter cela.

Le talk parle des biais qui freinent l’adoption de Kubernetes à travers un parallèle avec le mainframe. L’idée est que lors de leur sortie, le mainframe et Kubernetes fournissent tous les deux des fonctionnalités qu’on ne trouve pas forcément dans les solutions existantes, mais, alors que le mainframe s’est imposé sans problème, ce n’est pas le cas de Kubernetes.

Beaucoup de choses dans le talk, et parfois difficiles à suivre.

Les éléments que j’en retiens :

Un talk sur les solutions de no-code (à base d’interface-souris) ou de low-code (genre Excel mais pour du développement) qui permettent à des personnes ayant pas ou peu d’expérience de développement de pouvoir créer des applications.

Même si les choses progressent, le constat ne change pas depuis des années : on peut faire des choses avec ces systèmes, mais plus la complexité de ce qu’on veut faire augmente, plus leurs contraintes et limitations réduisent leur pertinence vis-à-vis d’outils de développement classiques.

J’ai été un peu brusqué sur la reprise du discours patronal sur “il manque 50.000 développeurs” qui repose sur des projections de 2012 et qui traduit surtout le sentiment que les personnes qui développent sont trop payées.

Une des propositions de valeur des solutions low-code est de pouvoir confier à des personnes moins compétentes et donc moins chères, des tâches qu’on confierait sinon à des développeurs et développeuses “classiques”.

Il serait plus courageux d’assumer la chose directement plutôt que se reposer sur des chiffres sortis de leur contexte.

Il s’agit d’un rappel sur les fondamentaux des échanges dans le SI au travers de l’histoire des ESB.

Pour les personnes qui n’ont pas connu ces outils et à qui ils ne donneraient pas envie, c’est surtout l’occasion de mieux expliquer certaines pratiques actuelles, et d’éviter de reproduire les erreurs du passé.

Je conseille ce talk quand il sera disponible en vidéo, mais comme Ilker a été mon manager pendant 5 ans, je ne suis pas tout à fait objectif.

Le sujet du talk n’est pas l’agile mais la vélocité, et son message est que d’augmenter le nombre de personnes qui développent n’est pas forcément la solution pour délivrer plus de fonctionnalités si le goulot d’étranglement est ailleurs.

Dans son raisonnement, Thomas essaie de montrer les effets induits par l’augmentation du nombre de personnes sur le développement, mais pour cela il mélange plusieurs choses : d’une part, ce qui augmente linéairement avec le nombre de personnes et ce qui augmente plus vite que le nombre de personnes ; d’autre part les choses qui arrivent dans tous les cas avec celles qui risquent d’arriver.

La conclusion semble être aller de soi, mais on a l’impression que, pour y arriver, il a mélangé des choux et des carottes.

J’ai eu le sentiment d’avoir assisté à deux demi-talks .

La première moitié du talk se base sur le livre Accelerate pour expliquer que, pour faire la différence aujourd’hui, il faut livrer plus vite et qu’il est possible de le faire sans baisse de qualité, et cela indépendamment de votre stack technique.

La deuxième moitié est un mélange de patterns à mettre en œuvre pour pouvoir délivrer plus vite et de conseils sur la posture de l’architecte dans un environnement de ce type.

Si je suis d’accord sur les solutions techniques exposées comme la fourniture des sondes de monitoring ou la prise en compte des défaillances, le discours sur la posture de l’architecte m’a laissé dubitatif.

Fabien défend l’idée d’un architecte de SI qui devrait avoir une posture de coach·e qui n’impose rien au projet mais qui est tout de même garant du SI. Dans une organisation, il est tout à fait normal que, de temps en temps, les besoins ou les priorités des applications et du SI ne soient pas les mêmes.

Dans ce cas, je pense qu’il est légitime que la personne qui porte la voix du SI, typiquement un ou une architecte SI, pèse dans la décision pour influencer les choix. On ne peut pas espérer que des projets défendent le point de vue du SI quand cela va à l’encontre du leur.

Du coup, affirmer que l’architecte doit être uniquement dans une posture de coaching revient soit à mettre en risque le SI, soit à tenter de ne pas assumer son pouvoir d’influence sur les projets.

Le talk raconte une refonte d’un domaine d’un SI réalisé pour un client, en insistant sur les aspects organisation et métier.

En effet, une refonte est un chantier d’envergure, et doit se piloter comme un programme, ce qui suppose planning, appuis politiques et négociations.

Les messages sont intéressants et font un bon tour d’horizon des sujets, il a juste manqué de parler un peu d’architecture.