[Retours Tech&Wine] Défier l'entropie : réécrire ses applications ou reprendre le contrôle ? - 4/5

Diane Lakestani était à la "Tech & Wine" qui se tenait au château de Montchat le 18 juin dernier. Découvrez ici ce son retour sur la conférence de Alexandre Jeambrun.

“Défier l'entropie : réécrire ses applications ou reprendre le contrôle ?”

Lors de la conférence "Défier l’entropie : réécrire ses applications ou reprendre le contrôle ?", Alexandre Jeambrun , coach craftsmanship chez Octo Technology, et architecte de systèmes d'information, a partagé des insights précieux sur la gestion de l'entropie dans les systèmes d'information. Voici un résumé des points clés abordés.

Avant de poursuivre, nous tenons à remercier Alexandre Jeambrun pour son temps et sa disponibilité lors du Tech and Wine. Cette conférence a été riche en enseignement et en connaissances.

Comprendre l'Entropie

Entropie : état de désordre d’un système.

Selon la deuxième loi de la thermodynamique, toute transformation entraîne une augmentation de l’entropie. Cependant, un système d’information n’étant pas un système fermé, il est possible de diminuer son entropie.

Les différentes sources d’entropie

1. Les Humains
   • Réduction de la taille d’une équipe : Moins de compétences disponibles.
   • Turnover : Perte de connaissances et de compétences clés.
2. La Technologie
   • Changement de frameworks : Nécessité de mettre à jour les compétences.
   • Failles de sécurité et bugs : Entretien constant nécessaire pour maintenir la sécurité et la stabilité.
   • Obsolescence : Mise à jour des bases de données et des systèmes nécessaires pour rester pertinent.
3. L'Environnement
   • Contrainte financière : Diminutions de budgets et changements de priorités.
   • Adaptation du système d’information : Nécessité de s’adapter à de nouveaux langages et technologies.

Gestion de la Complexité

Dans son livre No Silver Bullet — Essence and Accidents of Software Engineering, Fred Brooks, ingénieur informaticien américain, a défini la complexité essentielle d'un logiciel, par opposition à sa complexité accidentelle. Comme expliqué dans l'article de Ken Baum, Fred Brooks utilise le terme « accident » dans un sens philosophique, remontant jusqu'à Aristote. Par exemple, la complexité essentielle d'une chaise est d'avoir des pieds et un siège. Une qualité accidentelle de cette chaise serait d'être marron au lieu d'être rouge. Si vous enlevez de la chaise ses pieds et son siège, vous ne pourrez plus la considérer comme telle. Mais une chaise rouge devenue marron restera tout de même une chaise.

Pour Fred Brooks, plus on avance dans le temps, et plus la complexité accidentelle d'un système augmente. Il dépeint 3 types de complexité :

1. La Complexité Essentielle Il s'agit des problèmes inhérents au domaine d’application, par exemple des problèmes financiers dans le cadre d'une application sur les marchés financiers.

2. La Complexité Technique et Collaborative D'après la Loi de Conway , les systèmes reflètent les structures de communication des organisations qui les produisent. Toute organisation concevant un système se doit de collaborer, et cette collaboration induit en elle-même une complexité, car elle dépend de la façon dont les équipes sont organisées et communiquent. Une organisation, par définition, établit des règles et lois de communication, auxquelles elle obéit.

3. La Complexité Accidentelle Comme expliqué dans l'article d'Octo Technology, il s'agit de ce que l'on appelle communément la « dette technique ».

Face à ces complexités, beaucoup d'entre nous avons tendance à vouloir refondre entièrement une application. Mais souvent, cette refonte engendre encore plus d'entropie, au lieu de la réduire. Alexandre Jeambrun propose plusieurs clés permettant de réduire cette entropie résultant de la complexité accidentelle.

Humains : Clé pour Réduire l’Entropie

1. Agilité
   • D'après le 5e principe de l'agilité, Build projects around motivated individuals. Give them the environment and support they need and trust them to get the job done. : Construire les projets autour des individus et leur faire confiance réduit l’entropie.
   • Autonomie et Responsabilisation : Donner de l’autonomie aux équipes les responsabilise et augmente leur engagement. Il est essentiel de les laisser une certaine liberté, afin qu'elles soient soient motrices dans leur engagement.
   • Affirmation de la délégation : Ces zones de décision doivent être clairement définies.
2. Amélioration Continue
   • Formation et Compétences : Dédier du temps à la montée en compétences, par exemple une demi-journée à une journée par semaine est essentiel pour réduire le désordre interne des membres de l'équipe.
   • Résilience : Avoir des processus de documentation et d’onboarding efficaces pour rendre le turnover un non-évènement.
3. Motivation et Engagement
   • Donner du Challenge : Proposer des défis pour maintenir l'engagement.
   • La Pyramide de Maslow représente la pyramide des besoins essentiels d'une personne : L’accomplissement est la dernière étape pour garder un niveau d’engagement et de responsabilité élevé. Plus une personne est en haut de la pyramide, plus elle peut voir loin, et savoir où elle va, et donc prendre de meilleures décisions.

Technologie : Stratégies de Réduction de l’Entropie

Nous avons tous nos langages et Frameworks préférés, et nous blaguons souvent en critiquant tel système d'exploitation, ou tel langage. Mais ces croyances créent une dépendance à la technologie. Il est essentiel de rester agnostique et de ne pas mélanger les technos, qui restent juste des outils, avec le code métier qu'elles permettent de produire.

1. Architecture Modulaire
   • Séparation du Code : Séparer le code métier du code technique pour minimiser les risques de régression lors des changements de technologie.
   • **Modularité : Adopter une approche modulaire via les patrons de conception SOLID pour limiter les responsabilités et réduire la complexité. Octo Technology propose un article expliquant l'Architecture Hexagonale et le Clean Code.
2. Design Continu
   • Le Domain Driven Design est une approche permettant d'avoir une compréhension partagée des problèmes, par l'utilisation d'un langage commun (ubiquitous langage) pour tous les membres d'une équipe, quel que soit leur rôle, et par la granularisation d'un processus métier sous forme de « domaines ». Cette compréhension partagée du problème permet de fluidifier la communication et de se concentrer sur un domaine particulier.
   • Une conception en continu, sans ajouter de briques complexes dès le début, permet de maturer un projet. On ne peut décider d'une architecture parfaite et pérenne dès le début, car le projet vit et évolue en fonction de paramètres externes.
3. Refactorer et Adapter
   • Il est important de faire attention à ne pas laisser d'anciens patterns lors d'une refactorisation.
   • Limiter les responsabilités : il vaut mieux faire une seule chose, mais la faire bien.

Environnement : Facteurs Externes

1. Valeur et Argent
   • Générer de la Valeur : Toutes les applications existent pour générer de l’argent, directement ou indirectement. On cherche souvent à rentabiliser les applications rapidement, mais une application bien pensée aura peu d'obsolescence, et contrairement aux bien matériels, elle peut durer plusieurs décennies, avec bien sur de la maintenance.
   • Évolution des Applications : Les applications spécifiques deviennent génériques avec le temps, mais cela signifie souvent qu'il existe déjà des solutions similaires sur le marché. A force de vouloir rendre des applications plus « complètes », elles deviennent moins compétitives.
2. Adaptation et Généricité
   • Achats vs. Développement : Une application générique peut souvent être achetée, ou obtenue gratuitement si open open source, plutôt que développée en interne.

Conclusion

L’entropie est une force naturelle qui tend à désorganiser les systèmes d’information, mais elle peut être gérée grâce à des stratégies humaines, technologiques et environnementales. En appliquant des principes agiles, en favorisant la modularité et en restant adaptable, il est possible de maintenir le contrôle et de réduire la complexité.

La clé réside dans la formation continue, l’engagement des équipes, et une architecture bien pensée. Comme le bon vin, une application bien gérée se bonifie avec le temps.

Cette conférence a été intéressante pour Wanadev. En tant que petite structure, nous avons besoin d'optimiser notre temps, surtout au service IT/DevOps. Nous envisageons de partager nos compétences au sein de l'équipe, que ce soit en réseaux, ou au niveau de certains outils, afin de pouvoir répondre efficacement aux besoins en cas d'urgences, et de limiter l'entropie liée au silotage des connaissances. Nous aimerions parler de « domaines », plutôt que d'outils ou technos, et utiliser un langage plus ubiquitaire, afin de pouvoir mieux communiquer avec les différentes équipes, notamment en organisant des sessions de vulgarisation DevOps. Nous aimerions organiser régulièrement des temps de montées en compétences en interne, afin de nous enrichir mutuellement, et définir plus clairement les responsabilités. Cela renforcerait la confiance entre les différentes équipes, et les rendrait encore plus autonomes.

Suite à la journée "Tech & Wine", plusieurs articles sont disponibles. N'hésitez pas à aller les consulter :

• DevOps is Dead, les -Plateformes- sont le futur - 1/5
• La checklist ultime pour rendre vos applications cloud native !” - 2/5
• REX: transformer de l'Ansible+docker-compose en Helm+k8s - 3/5
• Vers un Nouveau Paradigme : Platform Engineering, Docker, DevOps et la Gestion de l'Entropie - 5/5