Conferences

Let’s discuss the subject that comes up in every tech brief. Real new approach or just another excuse reason for failing a project?

Around the table, Abdelkrim Marchiani, vice-president of Métropole Rouen Normandie, will set out his institutional vision to confront it with grumbling real-life developers.

This talk summarizes my 15 years making open source tools. Some of them have become popular (PostCSS, Autoprefixer, and Nano ID have more than 60M downloads per month) but most projects did not (but their fails taught me more than the successful projects).

Nous partons souvent du principe que tout le monde dispose d’une bonne connexion Internet et d’un matériel informatique de haute spécification. Bien que cela puisse être vrai dans certaines régions, ce n’est pas le cas dans le monde entier. Je souhaite attirer l’attention sur l’Afrique, où de nombreux pays luttent contre de faibles connexions 3G coûteuses, en fonction de la quantité de données consommées. Ceci est dû à l’infrastructure limitée du continent, conduisant à une dépendance aux connexions mobiles.

Compte tenu de ces circonstances, une utilisation efficace des données avec une bonne performance web devient une priorité. Ainsi, notre session se concentrera sur les défis rencontrés par les utilisateurs et les développeurs africains, et comment le téléchargement et l’exécution de grandes quantités de JavaScript exacerbe les problèmes de consommation de données et de performance. Nous explorerons comment les frameworks js existants ont tenté de résoudre le problème et comment Qwik, avec son approche innovante de la Resumability, présente une solution transformatrice à ces défis. Contrairement aux SPAs traditionnels, la Resumability de Qwik réduit considérablement la charge initiale de JavaScript, permettant aux applications de devenir interactives plus rapidement, même sur des connexions lentes.

Chez BforBank, on sort du plus gros refactoring de notre histoire… Et ça ne concernait pas le code. En l’espace d’un an, nous sommes passés d’une équipe solo à une quinzaine de Squads et de l’agilité at-scale. Facile ? Ou pas.

Parmi les enjeux de la restructuration, une question a une importance particulière : comment garder une homogénéité dans la qualité des développements et la stack, tout en donnant un maximum d’autonomie à chaque équipe ?

La réponse qu’on a trouvé : implémenter le Chapter Lead.

Garant des bonnes pratiques, créateur de poc et curieux, cet expert Tech est au service de la communauté de développeurs qu’il anime et qu’il doit tirer vers l’excellence. Inspiré du rôle de Chapter Manager de Spotify, le Lead Chapter met les mains dans le code et développe des features complexes mais aussi prend du recul pour voir quels sont les points de blocage dans le quotidien de sa communauté.

Vous repartirez avec notre retour d’expérience, nos fails, nos réussites et les nouveaux enjeux que cette mise en place a fait apparaître, notamment sur l’installation d’une culture du partage tech au sein de nos équipes

The introduction of the app router and React Server Components in Next.js brings an extra challenge for open-source maintainers of libraries based on this framework. How can we ensure backwards compatibility on older versions? Are there pain points to look out for with new versions? What are the best practices we can put in place to help us stay sane along the way? I’ll present my experience adapting the nuqs library to support both the pages and app routers, with a deep-dive into how those routers work, their differences and history, and which led me to contribute to the Next.js project.

Vous arrivez sur une nouvelle mission et là, c’est le drame : c’est un bon vieux legacy mal découpé et vous n’y comprenez rien. Après quelques semaines, vous rêvez déjà d’une refonte.

Mais ce legacy, bien que peu maintenable, apporte de la valeur aux utilisateurs. De plus, une refonte n’est pas envisagée par votre client. Une idée germe alors dans votre esprit : découper certaines parties de l’application. Mais une question reste en suspens : “Comment découper ?“.

Lors de ce talk, nous verrons comment une équipe s’est aventurée dans le refactoring d’un jeune legacy, du code de prod à la stratégie de tests. Nous verrons aussi comment transformer des intuitions en métriques et vous repartirez avec des heuristiques sur comment ré-architecturer votre legacy.

In my 30-minute presentation, I’ll discuss my transition from architecture to UX design. I’ll explore the parallels between these fields and share the valuable lessons I’ve learned. I’ll emphasize the importance of recognizing and utilizing the skills I already had in the new field.

I’ll also talk about the importance of empathy and recognicing the similar thinking approaches between both architecture and UX design. Understanding what users need and how they behave is crucial for designing spaces and digital interfaces that people feel confortable to use.

Through real-world examples and practical tips, I aim to highlight that UX designers can draw inspiration from diverse backgrounds and contexts, all that is required is to think outside of the box.

Une carrière est faite de choix et de circonstances. Si nous n’avons pas la main sur les circonstances, nous en avons chacun sur les choix que nous posons. Quitte à devoir faire des choix, autant poser ceux qui feront de notre vie professionnelle une aventure !

Durant ce talk, avec nos casquettes respectives de tech et recruteur tech nous vous livrerons tous nos secrets pour booster votre carrière tout en vous épanouissant. Pas de formules magique mais des tips allant des ressources clés, aux conseils pratiques, en passant par du personnel branding et un peu de « hacking de système » !

Que vous soyez dans une phase d’introspection, que le premier pas soit déjà initié ou que vous soyez simplement curieux ; que vous soyez encore étudiant ou avec une vie professionnelle déjà bien commencée : venez prendre un shot de motivation et de « bonnes pratiques » pour votre carrière !

De 2019 à maintenant, j’ai été impliqué dans le développement d’un système de gestion de la maintenance des ponts du Laos. C’est l’histoire de ce logiciel, dans ce contexte particulier de début de digitalisation d’un gouvernement et de collecte de données offline. Les challenges rencontrés: collecte sur le terrain sans connexion, un modèle de détérioration d’une université japonaise à implémenter, un hébergement sur un vieux serveur dans une salle d’archives.

Sur notre projet, comme souvent, la dette technique a commencé au jour 1.

Après 2 ans avec une dizaine de développeurs, l’application, découpée depuis son commencement en micro-services (7 puis 4), souffre de problèmes de couplages entre services, et donc, de gros problèmes de performances, comme des requêtes essentielles qui répondaient en plus de 44sec (p95).

Elle est déjà utilisée en production par de gros clients et cet enjeu de performance freine son développement.

Dans ce contexte, nous allons orchestrer une task force de 4 développeurs et Ops sur environ 3 mois pour fusionner ces micro-services en un monolithe. Cette fusion doit s’inscrire dans la roadmap d’un projet en évolution constante et gêner le moins possible les ajouts fonctionnels.

Dans ce talk, nous parlerons de pourquoi et comment détruire une archi micro services pour retourner vers un majestueux monolithe :

• Pourquoi un découpage en micro-services nécessite une maturité technique et métier que nous n’avions pas
• Comment nous avons commencé par instrumenter pour détecter les bugs ou variations de performances
• Comment nous avons analysé l’existant pour en déduire un plan avec des itérations régulières et moins risquées
• Comment nous avons utilisé des outils visuels pour embarquer et synchroniser les autres équipes
• Comment nous avons géré les problèmes rencontrés en cours de route

Avec ce talk nous espérons vous montrer qu’il est toujours possible de résorber ce genre de dette technique. Si nous l’avons fait, vous pouvez y arriver sur votre projet et bénéficier de notre retour d’expérience.

S’il se trouve un lien entre Richard Feynman et Léonard de Vinci en dehors de leur génie, c’est bien cette recherche de prioriser la simplicité. Il est difficile de faire simple et c’est pourtant nécessaire pour construire une compréhension approfondie d’un sujet. Et c’est ce que j’ai découvert lorsque j’ai décidé d’expliquer à mes filles comment fonctionne vraiment un ordinateur en le construisant en partant de “presque” rien. Vous allez découvrir en live une carte graphique VGA construite sur breadboard avec de simples composants, comment j’en suis arrivé la 😅 étape par étape et ma réflexion sur la difficile tâche de faire “simple”

Drupal 7 aura été supporté 14 ans (2011-2025). Cette version se permet de battre le record de longévité de Windows XP !

Après de bons et loyaux services, il est temps de le remplacer par… Drupal 10 !

Bien évidemment, la migration d’un site qui aura vécu de nombreuses années ne s’annonce pas chose aisée, d’autant plus que le gap des technologies est important.

Qu’à cela ne tienne : Armés d’Ansible, de QEMU/KVM, de Composer, de Drush, de PHP et de tous leurs copains, nous relèverons le défi !

La programmation fonctionnelle est souvent résumée à la manipulation de fonctions, que l’on peut passer en argument ou renvoyer. En somme, programmer avec des lambdas. Cette flexibilité de la manipulation de fonctions permet d’utiliser des opérateurs pour les composer, donnant lieu à un style de programmation que l’on appelle la “programmation tacite”, ou “point-free”, relativement populaire dans le monde Haskell, qui permet, malheureusement, très souvent, d’écrire des abominations, rendant le code illisible et incroyablement complexe à raisonner ! C’est pour cela que l’on lit très souvent qu’il n’y a pas de mérite à écrire des programmes dans ce style (et pour cause, une machine peut transformer du code normal en point-free et vice-versa).

Pourtant, il arrive parfois que les outils que l’on veuille manipuler soient “des genres de fonctions, et que la grammaire du langage ne permette pas de les manipuler trivialement. L’utilisation d’un encodage similaire à la programmation tacite est l’utilisation de la méthode .then, en JavaScript, avant l’intégration des marqueurs async/await, dont le rôle était de palier l’expressivité du langage avec une approche abstraite. Dans cette présentation, je vous propose de redécouvrir la programmation tacite, dans des contextes où c’est pertinent, permettant de mettre en avant l’abstraction pour généraliser des comportements. Découvrons ensemble le polymorphisme paramétrique, la variance (ou polarité) et la très amusante famille des profoncteurs et des Arrows pour abstraire l’application de fonctions, permettant de traiter, génériquement, des objets qui ressemblent à des fonctions.

Notre vie privée sur internet n’a jamais autant été mise à mal. Le business de la data opéré par les GAFAM, l’émmergence des “Data Brockers” ou encore les lois extra-territoriales (Cloud Act) sont tous de très bons exemples. Nous ferons donc un tour d’horizon de l’ensemble de ces menaces puis nous laisserons les sujets juridiques et géopolitiques aux personnes compétentes. Nous allons nous centrer sur la technique où comment reprendre le contrôle en cassant le modèle, voir même en le combattant. Pas besoin d’être un technicien chevronné, il y aura des outils pour tous les niveaux.