Un petit compte-rendu subjectif du DevFest Lille 2024

Le DevFest Lille 2024 avait lieu au Grand Palais

Les 6 et 7 juin 2024 j’ai participé au Devfest Lille. Ce billet est un compte-rendu complètement subjectif de ces 2 jours de conférences.

En préambule

Dans l’ensemble ce fut une très bonne expérience, un grand bravo et un grand remerciement aux conférenciers et à toutes les personnes qui ont travaillé à l’organisation en amont et sur ces 2 jours. C’est un travail de dingue qui permet au simple participant comme moi de pouvoir profiter pleinement de ce type d’événement.

J’y participais avec une dizaine de collègues de Norsys.

De manière générale, cette édition du Devfest Lille était sous le signe de l’IA et de l’impact écologique du numérique, à travers les 2 keynotes et par rapport à de nombreuses conférences. Cependant il n’y avait pas que cela et pour ma part en dehors de la première keynote je n’ai pas choisi les conférences ou les codelabs traitant d’IA.

L’ensemble des conférences sont désormais disponibles sur YouTube.

Keynotes

La keynote de Lê Nguyen Hoang traitait des problématiques de sécurité avec toutes les techniques d’intelligence artificielle (LLM, ChatBot, Recommandation, etc.). La conférence brossait un tableau des principaux risques de sécurité pouvant toucher l’utilisation de “l’IA”, avec une esquisse de contremesures possibles et des défis à relever dans ce champ.

La keynote de Marion Graefly présentait une vision de la société dans laquelle le numérique prend une place plus importante et directe dans la “polis” pour être mis au service de la société civil et de l’intérêt général. C’est une vision du numérique comme outil de la sobriété et de l’équité, à l’usage des citoyens. Cela m’a laissé une impression de vision utopique un peu naïve quand on regarde l’état du monde actuel. Néanmoins comme l’écrivait Edmond Rostand, “c’est la nuit qu’il est beau de croire à la lumière” et des propositions pour un avenir positif sont toujours une bonne chose, même si la trajectoire pour y arriver semble compliquée à mettre en œuvre.

Sécurité

La sécurité fait partie de ces thématiques dans le développement à la fois importante et invisibilisée, sur lesquelles il est important de faire une veille régulière.

Quand la cybersécurité n’est pas qu’une affaire de failles

J’ai eu l’impression d’apprendre plein de choses dans cette conférence de Sonia Seddiki. L’idée de la présentation est de montrer des exemples de détournement d’usage de certaines fonctionnalités à des fins cybercriminelles. La problématique venant ici du fait que ces détournement d’usage ne sont pas dus à des failles ou des erreurs de conception, mais juste à une exploitation habile d’une fonctionnalité légitime à une autre fin que celle initialement prévue. On parle d’usages catachrétiques. La catachrèse est à l’origine une figure de style qui consiste à détourner un mot ou une expression de son sens propre en étendant sa signification. Par extension on l’utilise ici pour un détournement de l’utilisation première d’une fonctionnalité.

Ainsi le DNS Tunneling, la stéganographie (l’art de dissimuler de l’information dans un média) ou les attaques par canal auxiliaire (side-channel attacks en anglais) relèvent de ces usages catachrétiques. Il est intéressant de voir en quoi ces techniques font partie de l’arsenal des cyberattaquants et peuvent être une des composantes d’une attaque à large échelle (par exemple la cyberattaque dont a été victime SolarWinds et ses clients).

Sécurité automatisée: Regardez vos failles en face.

Dans cette conférence, Marine du Mesnil présente une démarche pour améliorer la correction des failles de sécurité qu’elle a mis en œuvre sur ses projets.

Les failles sont des bugs mais ne ce ne sont pas des bugs classiques car ils sont moins directement visibles des utilisateurs et souvent leur correction est plus complexe ou compliquée à mettre en œuvre. En effet, les failles peuvent être dues à de multiples facteurs par rapport à la surface d’attaque qu’expose l’application : elles sont difficiles à identifier et souvent également complexes à corriger. Leur impact semble moins immédiat qu’un bug affectant une fonctionnalité utilisée par les clients et elles sont donc souvent dépriorisées par rapport à ces derniers. Par rapport à une anomalie fonctionnelle, il est parfois difficile de déterminer naturellement qui doit s’en occuper (penser au faille de type CVE impactant une bibliothèque utilisée par l’application). Les failles sont ainsi sciemment ou inconsciemment ignorées.

La première étape de la démarche est de s’outiller et d’automatiser au maximum la détection des failles : c’est une nécessité, on ne peut se baser uniquement sur une approche manuelle.

La deuxième étape proposée est d’utiliser l’outil Lean QRQC (Quick Response Quality Control) : l’idée est d’apporter une solution rapide à un problème en étant au plus près de la réalité du problème (sur les données réelles, dans les conditions de la production) en faisant travailler ensemble à sa résolution les équipes métier, applicative et sécurité. On part de l’identification du problème, sa caractérisation, sa sécurisation, l’analyse des causes racines et enfin les contremesures.

Cette analyse des causes racines et la mise en place de contremesures sont essentielles et s’inscrivent dans une logique d’amélioration continue et de formation des équipes.

Dans la conférence, plusieurs outils à tester ont été cités :

• L’outil d’analyse statique semgrep
• Des outils développés par Marine du Mesnil ou ses collègues pour différentes stacks techniques : spring-access-inspector (pour vérifier que les différentes routes d’une application Spring utilisent bien une annotation de contrôle d’accès de Spring Security), django-access-inspector (pour vérifier que les différentes routes d’une application Django ont un contrôle d’accès) , ACCENT (pour vérifier que les différentes routes d’une application PHP/Symfony ont un contrôle d’accès), RisXSS (une règle ESLint pour signaler les problèmes XSS sur une application Vue ou React).

Enfin, ils maintiennent la page Awesome Security Automation avec des liens vers ce type d’outils.

STOP à l’espionnage ! Comment disparaître d’Internet ?

Cette conférence d’Etienne Idoux et Mickael Alves permettait de faire prendre conscience de la quantité phénoménale de données personnelles que les GAFAM stockent sur nous et de la difficulté (voire de l’impossibilité) de disparaître d’Internet. Quelques pistes pour limiter l’exfiltration de ces données personnelles étaient également proposées. Intéressant l’application Terms Of Service : Didn’t Read, qui extrait des conditions d’utilisation d’application en ligne courant, les parties réellement pertinentes, perdues dans la masse du “blabla” juridique.

Documentation

La documentation et notamment la documentation-as-code est une de mes marottes, j’étais donc ravi de pouvoir voir 2 conférences sur le sujet, qui de plus étaient complémentaires.

Structurizr DSL : Au-delà des diagrammes vers l’Architecture-as-Code

Je connaissais le modèle C4 (mais sans avoir pu l’appliquer à grande échelle) de Simon Brown et dans une moindre mesure Structurizr. En effet je ne l’ai jamais directement utilisé, j’étais passé par PlantUML pour éditer mes modèles C4. C’est donc avec un intérêt non feint que je participais à cette conférence de Damien Raude-Morvan et je n’ai pas été déçu. La position du conférencier est que l’architecture n’a de valeur qui si elle est compréhensible et accessible. Je partage complètement et l’objet de la conférence est précisément de montrer en quoi Structurizr DSL aide à cette fin en dépassant certaines limites de solutions conventionnelles pour réaliser des diagrammes d’architectures.

Ainsi, les diagrammes peuvent s’adresser à des publiques divers ayant des attentes et besoins différents :

• les nouveaux arrivant sur un projet qui ont généralement besoin d’une vue globale
• Les “Ops” dont les besoins concernent le déploiement et l’exploitation des applications.
• Les responsables sécurité, qui ont besoin de voir les liens entre les composants, les interfaces avec l’extérieur, et globalement la position de l’application dans le SI.
• L’ensemble des parties prenantes extérieures à l’équipe applicative, par exemple d’autres équipes qui ont besoin de voir les interactions entre l’application et les autres composants du SI.

Si le “tableau blanc” reste un outil indispensable pour travailler l’architecture dans le cadre de réunions, il n’est pas adapté pour conserver l’information de manière durable.

Les outils classiques pour créer des diagrammes sont pratiques pour réaliser des croquis et des esquisses mais il est difficile de garder une consistance et un vocabulaire commun à travers l’équipe et à travers l’entreprise. De plus, la synchronisation entre les schémas et ce qu’ils représentent est problématique. C’est d’autant plus vrai quand les mêmes composants apparaissent dans des vues différentes. En cas d’évolution d’un composant, il faut penser à mettre à jour l’ensemble des diagrammes impactés. D’autant plus que ces diagrammes ne sont généralement pas centralisés et souvent stockés loin du code des composants qu’ils représentent. Enfin ces schémas ne portent pas de “sémantique” et ne sont pas “interrogeables” directement.

Sans être une panacée universelle, Structurizr fournit des solutions à la plupart de ces problèmes ou facilite la mise en place d’une discipline minimum pour améliorer le processus.

On exprime l’architecture avec ce DSL Structurizr : c’est une description textuelle, qui peut être mise avec le code de l’applicatif, être versionnée comme lui et faire l’objet des mêmes processus de revue et de validation. A partir de cette description textuelle de l’architecture, il est possible de générer différentes vues. Il est donc beaucoup plus facile d’être consistant.

Cette description textuelle est porteuse de sémantique et peut donc être plus facilement interrogée. C’est un travail à effectuer mais il ne serait pas impossible de parser le DSL pour alimenter une base de données relationnelles ou graphes pour pouvoir plus facilement effectuer des requêtes sur le modèle. En l’état, on peut déjà définir avec le DSL des vues qui filtrent certains composants ou mettent l’accent sur certaines parties.

Enfin, il est possible d’y intégrer des ADR (Architecture Decision Records) et il est possible de générer un site statique à partir de la description en Structurizr DSL (via un projet de l’écosystème). Il est tout à fait possible d’intégrer les diagrammes d’architecture avec une documentation technique en Markdown ou AsciiDoc.

Cette présentation m’a vraiment donné envie de creuser plus C4 et d’investiguer l’utilisation de Structurizr et de l’ensemble des outils associés.

La doc va bien, ne t’en fais pas

Cette conférence de Damien Lucas était centrée sur l’utilisation d’arc42 comme template pour guider et faciliter l’écriture de la documentation technique, en exploitant habilement différents outils pour générer de la documentation de manière automatique quand c’est possible.

arc42 j’en avais entendu parler il y a longtemps dans un podcast mais je n’avais pas pu l’utiliser à l’époque.

L’objet de la conférence était de présenter le template de arc42, de proposer une manière de l’utiliser et de mettre à profit différents outils pour faciliter la génération de certaines parties de la documentation

• schemaspy pour générer la documentation de la base de données
• les différents outils autour d’OpenAPI pour générer la documentation de l’API Rest.
• compodoc pour générer la documentation d’une application Angular ou Nest.
• docker-compose-diagram ou docker-compose-viz pour la génération de documentation à partir des fichiers Docker Compose.
• k8sviz ou KubeView pour la génération de visualisation de cluster Kubernetes.

Cette présentation faisait explicitement le lien avec la conférence sur Structurizr et C4, qui peuvent avantageusement être utilisés dans ce contexte.

En plus d’arc42, il était également fait référence à l’approche Diátaxis pour la création de documentation technique.

Dans l’ensemble une très bonne conférence quand on s’intéresse de près ou de loin à la documentation ou à la mise en place d’un processus documentaire. Selon son contexte, arc42 peut définitivement être une bonne idée pour structurer sa documentation de manière souple sans avoir à réinventer la roue.

Domain Driven Design

Le DDD fait partie de ces sujets qui m’intéressent et sur lequel je voudrais monter en compétence, sans avoir eu l’occasion de mettre en pratique, même si justement ma pratique quotidienne me fait voir tout l’intérêt de cette approche.

Il y avait 2 conférences sur la DDD

Model Mitosis : ne plus se tromper entre les microservices et le monolithe

Cette conférence de Julien Topçu et Josian Chevalier était très dynamique et fun, mais surtout très intéressante. Elle montrait par l’exemple une série d’itérations de refactoring de code dans un esprit DDD. Ce qui était intéressant ici c’est d’avoir les questionnements et les tâtonnements pour aboutir au résultat final.

En effet, dans une base de code on a un concept qui peut se révéler avoir finalement un sens différent dans 2 contextes métier distincts. Pour supprimer cette tension de modèle et avoir des frontières bien établies entre ces 2 contextes métiers, on peut avoir la tentation de dupliquer ce concept.

Cependant, il faut faire attention que ces 2 concepts dupliqués, ne restent pas couplés “conceptuellement”. La problématique est que trouver et définir les frontières des contextes à partir des concepts, n’est pas forcément l’idée appropriée. Il faut alors essayer de trouver les frontières en se basant sur les comportements plutôt que sur les concepts.

Il peut être nécessaire de mettre en place un shared kernel temporaire (“transitional shared kernel”) qui représente une zone d’incertitude conceptuel à un moment et qui éventuellement pourra être extrait sous la forme d’un “generic subdomain”.

La métaphore est celle de la mitose cellulaire comme le titre de la conférence le laisser présager, mais les 2 points importants à retenir sont pour moi

• l’utilisation de ce “transitional shared kernel” qui ne doit contenir que des concepts qui ont bien la même signification métier, la même représentation et les mêmes invariants.
• passer à une recherche de frontière entre les contextes en se basant sur les comportements plutôt que les concepts métiers quand il y a des dépendances inextricables entre ces concepts métier.

Cela fait partie de ces conférences durant lesquelles j’ai beaucoup appris mais que j’aurais certainement besoin de revoir pour vraiment m’approprier ce qui a été dit. A priori une conférence similaire a été donnée à MiXiT 2024.

Banalisation du DDD ou pas ?

Il était dommage que cette conférence de Bruno Boucard soit une des dernières de la dernière journée, je pense que son accueil en a un peu souffert. Elle n’en restait pas moins très intéressante.

D’après la présentation de Bruno Boucard, cette conférence est sa prise de recul par rapport à un coup de gueule qu’il a eu sur LinkedIn (je pense que c’est ce post).

La conférence revenait donc sur l’importance des patterns stratégiques du DDD : même si les patterns tactiques ont leur rôle, sans la partie stratégique on finit par faire du DDD sans âme ou juste du code qui en surface semble appliquer la DDD mais qui n’en respecte pas l’esprit. On débouche alors sur du Cargo Cult DDD.

Au-delà de ces points, Bruno Boucard présentait également la démarche qui est la sienne pour pouvoir réellement mettre en œuvre la DDD. Dans ce cadre il évoquait l’importance d’outil comme le “Event Storming” (d’ailleurs Bruno Boucard et Pierre Perrain avait fait une interview pour les CastCodeurs sur ce sujet en 2020).

La présentation était très riche mais il faut avouer qu’après 2 jours de conférence cela pouvait être un peu rude. Je retiens quand même :

• qu’il ne faut pas être DRY entre 2 Bounded Contexts, il ne faut faire aucun compromis sur l’autonomie de ces derniers.
• L’influence de la topologie des équipes.
• Il y a des ressources intéressantes sur Domain-Driven Design Crew
• Il faut lire le livre original d’Eric Evans, même si ce dernier est d’un abord difficile, si on veut vraiment avoir la substantifique moëlle de la DDD

Comme la conférence précédente sur la DDD, elle méritera que je la revois.

Numérique & Environnement

Il est difficile de ne pas être concernés actuellement par les impacts environnementaux du numérique, et c’est un sujet au cœur des préoccupations de Norsys depuis bien longtemps.

J’ai une idée pour réduire l’empreinte environnementale du numérique par 4

Cette conférence de Tristan Nitot amène a prendre du recul par rapport à notre métier et la manière dont nous faisons les logiciels. Le plus gros de l’empreinte environnementale du numérique est dû au matériel, matériel qui est vite obsolète : la loi de Moore implique que les performances des microprocesseurs augmentent régulièrement tout en voyant leur prix unitaire baisser. Cela a pour conséquence que côté logiciel non seulement il y a la course à la fonctionnalité pas toujours utile mais de plus l’optimisation des logicielles n’est pas économiquement intéressante : cela conduit à la loi de Wirth (“les programmes ralentissent plus vite que le matériel n’accélère”). On est dans un cercle vicieux qui nous amène à faire du sur place et à un beau gâchis numérique.

Seulement voilà, on peut constater que la loi de Moore est presque morte : les CPU ne s’améliorent presque plus depuis 2015, les fréquences d’horloge n’augmentent plus depuis 2003 et le prix des microprocesseurs ne baissent plus.

Cela amène Tristan Nitot a énoncé le principe erooM (Effort Radicalement Organisé d’Optimisation en Masse) dont l’objectif est de remettre l’optimisation et la recherche de performance logicielle au centre du développement logiciel. Comment ? En faisant un travail pédagogique pour augmenter les compétences des développeurs en les aidant à trouver les bons algorithmes, en identifiant les éléments critiques consommateurs de ressources et en optimisant de manière pertinente ce qui peut l’être.

En général, on consacre du temps et de l’énergie à l’optimisation sous la contrainte, quand on a pas d’autre choix : on ne peut pas faire évoluer le matériel (penser à des systèmes embarqués auquel on ne peut accéder facilement car ils sont dans l’espace ou sur une autre planète par exemple), ou des traitements batch qui durent trop longtemps (ils prennent plus de 24 heures). Tristan Nitot propose d’introduire une nouvelle contrainte pour inciter à optimiser, morale celle-ci, qui est de respecter les limites planétaires.

Avec la loi de Moore qui est en passe de ne plus être vérifiée, il y a une opportunité morale et économique à travailler à l’optimisation des logicielles afin de produire des applications respectueuses des limites planétaires. Dans tous les cas, la proposition est intéressante et est actionnable.

Comment automatiser les outils d’éco-conception de service numérique ?

Cette conférence de Nicolas Bordier et Raphaël Lemaire était pour l’essentiel un benchmark de différents outils plus ou moins open source/gratuits permettant d’estimer l’impact écologique du code. Actuellement le focus de l’estimation de cet impact écologique du code concerne surtout les “gaz à effet de serre” (GES).

En écho à la conférence de Tristan Nitot, il était rappelé que tout outil visant à l’amélioration des performances était pertinent (par exemple Lighthouse pour les applications front). Néanmoins le benchmark se focalisait sur quelques outils vraiment spécifiques à l’estimation de l’impact écologique.

La “baseline” du benchmark a été définie avec une Analyse du Cycle de Vie (ACV). Cela a permis, par exemple, d’affiner le benchmark en écartant des outils dont les résultats étaient trop incohérents par rapport à ceux obtenus avec l’ACV. Ils en ressortent un benchmark pour GreenIT Analysis, Kastor, Fruggr et Green Tracker, chacun ayant des points forts différents et une certaine complémentarité avec les autres.

Ont également été cités lors de la présentation EcoSonar, Heart, Scaphandre, PowerAPI, KEPLER (Kubernetes Efficient Power Level Exporter) et e-footprint. Devant le grand nombre d’outils dans ce champ, certains pleinement open source et gratuits, d’autres payants (partiellement ou en totalité) les deux conférenciers en appelaient aux contributions et regrettaient que les efforts de certaines entreprises se portent plus sur la création de nouveaux projets que la contribution aux outils open source existants.

Dans l’ensemble, une conférence qui était complémentaire à celle de Tristan Nitot, avec un accent sur l’outillage à disposition pour estimer l’impact écologique des logiciels, avec une méthodologie d’évaluation de ces outils.

Performance

La performance est une problématique souvent laissée de côté mais qui peut devenir prioritaire et sur laquelle il vaut mieux être sensibilisé un minimum. Et comme on a pu le voir précédemment, il y a un lien fort avec les impacts environnementaux du numérique.

Faut-il privilégier la performance ou la lisibilité ?

Une conférence courte dans laquelle Jonathan Meunier discute de la tension entre du code performant par rapport à du code lisible. Il n’y a pas de réponse à la question posée en titre mais le conférencier penche quand même plus du côté de la performance, sachant que la lisibilité a une dimension très subjective alors que la performance peut offrir des objectifs mesurables.

Il est vrai que la lisibilité c’est surtout arriver à se mettre d’accord sur un ensemble de règles que l’équipe de développement suit et qui sont éventuellement mise en œuvre via un linter. Ainsi même si la lisibilité est importante pour la maintenabilité du code, ce sont surtout des conventions à suivre et auxquelles s’habituer. Il vaut donc mieux consacrer son énergie à l’amélioration de la performance. Maintenant, il faut aussi trouver un compromis, et faire en sorte que le code reste compréhensible et maintenable.

Sous le capot d’une application JVM — Java Flight Recorder / Java Mission Control

Dans cette conférence Guillaume Darmont présente de manière pratique les outils Java Mission Control (JMC) et Java Flight Recorder (JFR). A noter qu’il a donné une conférence similaire à Devoxx France cette année. A travers le débogage d’une application calculant le git hash d’un répertoire, JFR et de JMC sont utilisés pour identifier les points problématiques de l’application.

Concrètement, en lançant son application, il faut passer des paramètres à la JVM pour que des événements JFR soient émis et qu’un fichier les enregistrant soit créé. JMC peut alors être utilisé pour lire ce fichier. A noter que le format du fichier est standardisé et qu’IntelliJ Idea par exemple peut également le lire et l’exploiter. Il faut compter un overhead de 1 à 3% quand on ajoute JFR. A priori pour une utilisation en production il faut une JVM sous licence commerciale. A noter que les virtual threads ne sont pas reconnus comme tel pour l’instant et apparaissent comme étant le même thread dans JMC (problématique qui vient a priori du fait que les virtual threads ont tous un nom “vide” — enfin la “chaine vide”. En conséquence, ils correspondent tous au même thread pour JMC).

L’ensemble était clair et didactique. On pouvait constater que les recommandations de JMC étaient pertinentes. Pour la petite histoire cela a même permis au conférencier de trouver un bug de performance dans les tests de permission d’un fichier (cela sera normalement corrigé dans une des prochaines version du JDK).

Au final, il est fort commode d’avoir ces 2 outils accessibles simplement et gratuitement pour investiguer les problèmes de performance d’une application sur une JVM. L’interface et l’expérience utilisateur sont certes perfectibles, il faut apprendre à utiliser l’outil (mais bon la performance, c’est comme la sécurité cela reste un métier, il faut aborder cela avec une certaine humilité) mais de nombreuses fonctionnalités sont présentes et les recommandations sont pertinentes. Bref, il n’y a pas à se poser de questions quand on a une application tournant sur une JVM qui a un comportement étrange relativement à la performance (sous-utilisation des ressources sur forte charge, GC avec un comportement qui semble bizarre, etc.).

Développement

Il y a un certains nombres de conférences auxquelles j’ai participé que je n’ai pas réussi à classer plus spécifiquement que relevant du développement au sens large.

Faire évoluer vos APIs HTTP, une approche pas-à-pas

Dans cette conférence, Nicolas Fränkel s’intéressait à la manière de versionner une API en mettant en application avec Apache Apisix. La présentation brossait un bon tableau des problématiques de versionning d’API et proposait une série d’étapes pour adresser la migration d’une API avec une API Gateway en général et avec Apache Apisix en particulier.

En lui-même Apache Apisix est une solution open source basée sur NGINX qui se configure via un système de plugins existants ou que l’on peut développer (en Lua). Le code de démonstration est disponible sur GitHub. A noter, même si elle est juste au statut de draft et pas encore implémentée dans les navigateurs, la proposition de header de dépréciation. Intéressant également l’idée que dans certains cas, il peut être opportun de déprécier le contenu renvoyé par le endpoint HTTP plutôt que déprécier le endpoint en lui-même, ce qui permet de changer le contenu plutôt que le endpoint exposé.

Cette conférence a mis sur mon radar Apache Apisix en tant que solution d’API Management à considérer.

Mon setup DevContainer: Un poste de Développement, Reproductible et Flexible

Cette courte conférence de Nicolas Focqueu m’a permis de découvrir les Development Containers à côté desquels j’étais complètement passé.

Les Development Containers sont une spécification et un ensemble d’outils qui permettent de faciliter l’utilisation de conteneurs comme environnement de développement. Cela peut permettre de fournir un poste de développement flexible et reproductible. Comme c’est Microsoft qui en est à l’origine, c’est bien intégré dans Visual Studio Code mais également dans IntelliJ IDEA.

C’est une approche development-environment-as-code avec un fichier JSON qui définit l’environnement de développement conteneurisé. Cela peut s’utiliser depuis l’IDE mais également depuis GitHub Codespaces ou Coder (faire attention à la facturation quand on l’utilise depuis un IDE en ligne). Microsoft propose des conteneurs spécifiques pour Development Containers. Pour des environnements de développement un peu complexes dans lesquels on a besoin d’une base de données par exemple, il est possible d’utiliser Docker Compose. Au final, sur Windows les seuls prérequis sont WSL et Docker.

C’est intéressant pour assurer un environnement de développement reproductible, notamment dans des contextes Open Source ou Inner Source pour lesquels cela peut simplifier les actions à réaliser avant de contribuer. Définitivement à tester et surveiller.

La dette technique : comment communiquer dessus à l’ensemble des équipes, au delà de la technique

Cette conférence courte de Suzanne Daurat s’attaquait à quelques idées reçues sur la dette technique pour donner des outils aux développeurs afin de pouvoir communiquer sur ce concept auprès de “non-techs”. Cela s’inspire des idées du billet “The Constant Gardener: What are we getting wrong about Technical Debt?”.

C’était intéressant quand on ne connait pas trop le concept de dette technique ou qu’on a besoin d’un rafraichissement sur le sujet. En complément pour ma part, j’aime bien l’article de Martin Fowler sur le sujet.

Et si on implémentait une Machine à Etats pour aider la petite souris ?

Cette conférence de Laurine le Net était pédagogique et rafraichissante. En partant d’une implémentation pour résoudre une problématique métier lors d’une mission, une machine à état est implémentée pas à pas.

Ici pas d’utilisation du modèle de conception classique Etat, c’est une implémentation directe d’une machine à état fini telle qu’on pourrait l’avoir avec Spring Statemachine par exemple.

La présentation était claire et le “live coding” bien mené, rendant l’ensemble très agréable à suivre.

Maîtriser la Hype : Passion versus Raison

Cette conférence de William Leemans présentait une approche pour tempérer la “hype”, un moteur intense de motivation mais qui s’étiole rapidement. La “hype” est ici définie comme un engouement intense et souvent temporaire sur une technologie ou un concept. Cela part du constat que cette “hype” est quand même une source de motivation et d’opportunité mais que pour en tirer le maximum dans le contexte de projets personnels il faut la “tempérer”. Il est ainsi opportun de définir un cadre et des règles sur ses projets “HDD” (Hype Driven Developement), par exemple en définissant une durée maximum au projet.

Dans un contexte professionnel, cela peut correspondre à la mise en place de spikes, qui permettent de tester rapidement une idée ou une technologie. Un autre idée est d’avoir une approche similaire à celles des ADR (Architecture Decision Records) en documentant la décision technique avec le contexte dans lequel elle a été prise et éventuellement ces impacts (positifs, neutres ou négatifs).

Conclusion

Je ne regrette pas ma participation, j’ai eu l’impression d’avoir beaucoup appris sur ces 2 jours. Je repars avec plein de nouvelles choses sur mes radars à suivre et explorer.

Remerciement

Je remercie encore une fois les conférenciers et toutes les personnes qui ont travaillé à l’organisation du Devfest Lille.

Je remercie également Norsys de nous avoir permis de participer à cette conférence.

Enfin, je remercie mon collègue Thomas Verhoken pour sa relecture attentive et ses remarques sur ce billet.