Deux semaines après, il est temps de faire le bilan de notre passage au BDX I/O. Nos deux Kaïbers présents reviennent en quelques lignes sur les temps forts de leur journée de conférences :

• Retour de François Garrigues : 

“Comment on n’a (toujours) pas codé de back-end après 1 an en production” par Marc Gavanier :

Je m’attendais à une start-up mettant en avant le low-code / no-code et des fondations basées sur des 3rd party. En réalité, rien de tout ça !

Embarqué sur des projets pour le compte de l’État, cette (très) petite entreprise est incroyablement débrouillarde et navigue de MVP en POC pour adapter ses développements aux ressources dont elle dispose.

Un état d’esprit et une vision très intéressante et singulière sur la façon d’aborder des projets qui sont pourtant de grande ampleur.

“Concevoir des paramètres écologiques dans les applications” par Thomas Thibault :

Notre industrie peine à être verte : fabrication des terminaux, déploiement d’Internet, data center… Mais une partie de notre impact écologique est liée aux usages.

Les applications sont de plus en plus gourmandes en ressources, mais elles souffrent surtout d’une conception qui ne prend pas du tout en compte l’absence écologique.

Cette approche est au cœur du projet de recherche « Limites Numériques ».

Que ce soit par le lexique des paramétrages qui peut être plus clair sur le gain écologique, sur des paramètres absents, ou plus simplement par le fait de privilégier l’économie d’énergie à la performance, Thomas Thibault nous livre un bon nombre de bons réflexes à adopter pour nos prochains projets.

“Oups, j’ai oublié de faire mes slides !” par Xavier Noya et Alexandre Nédélec : 

Plutôt audacieux et amusant : le conférencier est venu sans présentation et son camarade l’a réalisé en temps réel via Slidev.

Cette conférence est donc une pure démonstration de cet outil très intéressant : une solution open source de présentation contrôlée par le code.

Basée sur la syntaxe Markdown, chacun peut le personnaliser à sa sauce et y embarquer des technologies compatibles – notamment des frameworks JS.

Très sympa pour booster un peu les ReadMe.md de nos projets avec des présentations un peu plus dynamiques et structurées !

• Retour de Kossi Gbegnon : 

« Architecture d’entreprise et numérique responsable : les 2 font la paire » par Dorine Periolat et Léa Rolland-Thongkham :

Aujourd’hui face aux enjeux climatiques, la responsabilité du numérique est plus que pointée du doigt. C’est d’ailleurs le thème de cette 8ème édition de l’évènement numérique BDX I/O et c’est aussi l’une des raisons qui m’a poussé à suivre cette conférence.

Dans un premier temps les deux conférencières ont présenté le contexte et les enjeux liés au numérique, à savoir la mutualisation des compétences des collectivités des communes de la métropole bordelaise, engendrant un énorme parc applicatif à gérer avec plus de 1300 applications, 500 projets actifs et 21500 utilisateurs. L’évaluation de l’empreinte carbone de cette mutualisation s’élève à 12 732 tonnes de CO2 en 2022. Quant aux enjeux, les collectivités font face à de nombreux risques de cyberattaques, au besoin de maîtriser et de rendre efficaces tous leurs systèmes d’informations, aux différentes politiques réglementaires dont le RGPD et évidemment aux enjeux climatiques.

Ensuite, Léa nous a définit ce qu’est le numérique responsable et Dorine de nous faire connaître l’architecture d’entreprise.

En effet, le numérique responsable est une démarche collective et d’amélioration continue visant à réduire les impacts environnementaux, économiques et sociaux du numérique. Il est à noter aujourd’hui que le numérique représente 4% des émissions mondiales de gaz à effet de serre et pourrait doubler d’ici 2025. Par ailleurs, la plus grande partie de l’impact du numérique est consacrée à la phase de fabrication des différents terminaux à hauteur de 78% contre 21% pour la phase d’usage. Ainsi en mettant l’accent sur la réparation, la réparabilité et l’allongement des équipements numériques, on serait encore plus éco responsable.

Enfin, certaines politiques du Numérique Responsable (NR) ont été mises en place au sein de la Direction Générale de Bordeaux métropole, à savoir la politique de sensibilisation et d’accompagnement, une politique d’achat responsable pour le numérique qui exige certaines clauses d’achat sur le marché et une politique d’éco conception.

En ce qui concerne l’architecture d’entreprise, c’est aussi une démarche qui permet la maîtrise des projets de conception et d’évolution de l’organisation. Faire de l’architecture d’entreprise revient à définir un cadre de référence dont le but est non seulement de maintenir la connaissance d’un système d’informations mais aussi de garantir la cohérence de ce dernier et son alignement avec les orientations stratégiques des métiers. Ce cadre de référence doit être mis en place en collaboration avec tous les acteurs du projet et doit être utile, utilisable et utilisé. Puis ce cadre doit être partagé par les architectes, ils sont aussi amenés à sensibiliser sur une culture commune et à surtout apporter une amélioration continue au cadre de référence. 

Enfin le numérique responsable et l’architecture d’entreprise font-ils vraiment la paire ?

Sur cette partie, je m’attendais davantage à découvrir la complémentarité entre les 2 thèmes précédemment définis. Finalement la présentation s’est plutôt appuyée sur des termes assez techniques et a été un peu trop rapide pour moi. 

Pour résumer, d’énormes améliorations s’opèrent afin de limiter l’impact numérique même si celles-ci restent lentes comparées à l’évolution du secteur. Il y a également une forte sensibilisation autour du numérique responsable mais ces efforts restent pour le moment en grande partie théoriques.

« Une architecture pour tester son front-end » par Alexia Souvane :

Il n’est plus question aujourd’hui de démontrer les bienfaits des tests dans une application. Et comme Alexia l’a bien formulé : ‘Si tu n’écris pas de tests, ton logiciel ne peut pas être de bonne qualité’.

Elle a ainsi débuté sa présentation en nous montrant les différents types de tests que l’on peut rencontrer sous forme d’une pyramide. Tout en bas de la pyramide on retrouve les tests unitaires, au milieu les tests d’intégration puis tout en haut les tests end-to-end. Ainsi les tests unitaires sont tout en bas car plus nombreux, ce qui est raisonnable dans le sens où ils sont rapides à exécuter, peu coûteux et apportent un feedback très rapide sur les développements contrairement aux tests d’intégration où il faudrait attendre un feedback après la CI et pour les tests end-to-end ou tests manuels pour lesquels il faudrait attendre que l’application soit en pré production ou production.

Ensuite, elle nous explique à quel point les tests unitaires sont complexes à mettre en place côté front-end par rapport au backend où il n’y a que la logique. En effet, le front-end d’une application gère 3 grands axes : la vue, la mise à jour des données et le stockage des données à travers les APIs. Ainsi tester un comportement d’une application front-end sans un découpage spécifique ou architecture serait très complexe. D’où la nécessité de bien réfléchir en amont à une architecture testable.

Au final elle nous présente 2 techniques assez courantes permettant d’arriver à une architecture testable. Ce sont bien évidemment la ségrégation des responsabilités : plutôt que de mettre ensemble l’affichage, le traitement de mise à jour et de stockage des données, nous allons les séparer et avoir un couplage faible entre ces 3 axes. Et la deuxième technique n’est d’autre que l’inversion de dépendance.

« Au cœur de nos objets, faut-il abandonner la POO ? » de Gaëtan Eleouet :

J’étais plutôt très curieux d’assister à cette présentation car j’ai beaucoup développé en utilisant la pratique POO (Programmation Orienté Objet).

Finalement, la présentation s’est plus centrée sur des acronymes très prisés des développeurs crafts et avec une brève explication sur chacun d’eux :

• KISS (Keep It Simple, Stupid),
• DRY (Don’t Repeat Yourself) – avec une petite ambiguïté intéressante soulevée ici. En effet, on a l’habitude de se dire que DRY est une pratique permettant d’éviter la duplication du code. D’après Gaëtan, il ne s’agit pas du code mais plutôt de la connaissance d’un élément de l’application.
• WET (Write everything twice),
• TDA(Tell, Don’t ask),
• YAGNI (You ain’t gonna need it),
• GRASP (General Responsibility Assignment Software Patterns) qui est plutôt rare et qui permet de nous aider à savoir où positionner les comportements dans nos objets,
• SOLID.

Ce fut une belle présentation nous démontrant qu’on aura besoin de la POO pour encore très longtemps. La bonne question à se poser est de savoir si on pratique la POO de la meilleure des manières.