L'article explore la problématique des animations CSS redondantes dans les projets web. L'auteur souligne que les animations de base comme les fade-in, slide ou zoom sont souvent recréées de manière indépendante, entraînant une duplication inutile de code et une maintenance complexe. Il propose une solution pour standardiser ces animations en consolidant les @keyframes, transformant ainsi un système chaotique en un système clair et prévisible. Une lecture utile pour les développeurs front-end cherchant à optimiser leur code et leur flux de travail.

Chez Les-Tilleuls.coop, on réhabilite la maintenance logicielle, souvent perçue comme une corvée, mais qui est en réalité une discipline exigeante et formatrice. Contrairement à la création ex nihilo, la maintenance confronte au réel, aux imprévus et à la complexité, tout en étant un travail invisible et préventif. Elle enseigne la résilience, l'empathie et l'importance de concevoir des systèmes durables. Dans un monde obsédé par l'innovation, la maintenance est un acte écologique et économique, permettant de faire durer les projets au-delà de leur phase initiale.

Cette page recense les projets Open Source d'Alsacréations sur Github :

• Kiwipedia - Nos guidelines, checklist et bonnes pratiques d'intégration web
• Bretzel - Layouts CSS réutilisables et utilitaires
• KNACSS - styles modernes et accessibles pour les éléments HTML natifs courants
• MyDevice - Taille, résolution et infos de votre device
• UniClaude - Explorateur de caractères Unicode
• Spätzi - Testez et corrigez vos contrastes de couleurs non accessibles
• Schnaps.it - Générateur de Lorem Ipsum alsacien, gal!
• Reset - Reset CSS moderne et accessible
• Liquid - Un gabarit de page responsive en Grid Layout
• Quetsche - Compression d'images. Simple. Basique
• Cuillère - Générateur de QR codes personnalisés
• Palette - Générateur de palettes de couleurs accessibles
• Quiz - Modèle de quiz interactif avec calcul du score
• IEscape - Aidez l'Alsacréature à échapper à Internet Explorer
• Pepin #archive - Structure par défaut de plugin jQuery

Ce billet de blog explique pourquoi la qualité d'un logiciel dépend avant tout d'une bonne conception fonctionnelle, bien avant l'écriture du code. Mathieu Eveillard souligne l'importance de bien définir les besoins des utilisateurs et de concevoir des solutions adaptées avant de se lancer dans le développement. Il décrit les différentes étapes du processus, de la découverte des besoins à la mise en œuvre, en passant par la conception fonctionnelle, qui consiste à décrire le "quoi" avant le "comment". Il propose également quelques outils et pratiques pour cette étape cruciale, comme la définition de personas, l'étude des processus et la modularité.

L'auteur partage une réflexion sur le pragmatisme en développement logiciel, inspirée par le film "Whatever works" de Woody Allen. Il critique les dogmes et les débats stériles entre experts, souvent centrés sur des définitions, et plaide pour une approche plus flexible des bonnes pratiques. Il illustre son propos avec des exemples comme le TDD, la pyramide de tests et les tests en intégration continue, soulignant que l'essentiel est de s'adapter à la situation et aux besoins de l'équipe. Le temps et les résultats devraient être les seuls juges de paix, et le doute doit rester un moteur d'amélioration continue.

Cet article présente les techniques de pagination des API pour les systèmes évolutifs, illustrées par des exemples concrets de Twitter (X) et Spotify. L'article explique pourquoi la pagination est nécessaire pour gérer efficacement de grands ensembles de données, en évitant les problèmes de lenteur, de consommation de bande passante et de mémoire. Il détaille deux méthodes principales : la pagination Limit-Offset, où le serveur divise les données en pages et renvoie un nombre limité de records en fonction d'un décalage (offset), et la pagination par curseur, qui utilise des identifiants uniques pour naviguer à travers les données. L'article met en avant les avantages et les inconvénients de chaque méthode, aidant les lecteurs à choisir la stratégie de pagination la plus adaptée à leurs besoins.

L’article explore la distinction cruciale entre User Need (besoin utilisateur) et Product Need (besoin produit) dans le développement de produits digitaux. Un User Need exprime un problème ou une frustration perçue par l’utilisateur, souvent formulée comme une solution concrète (ex. : « Je veux un bouton plus gros »). Le Product Need, en revanche, est le problème business sous-jacent identifié après analyse (ex. : « Assurer une découvrabilité optimale des actions principales »). L’auteur souligne l’importance de ne pas confondre les deux : écouter une demande utilisateur, c’est entendre une solution proposée, tandis que comprendre un besoin, c’est identifier le problème réel à résoudre. Pour y parvenir, des outils comme la méthode des 5 Pourquoi ou l’observation terrain permettent de creuser au-delà des demandes apparentes et d’éviter des solutions techniques inutiles. L’objectif ? Créer des produits qui répondent à des besoins profonds, et non à des demandes superficielles, en alignant valeur utilisateur et objectifs business.

Exemple marquant : Un livreur demandant un vélo plus léger cache en réalité un besoin d’optimisation logistique.

L’article plaide pour une utilisation plus réfléchie et minimaliste des animations dans les interfaces numériques. Plutôt que de multiplier les effets visuels pour séduire, il invite à privilégier la retenue et l’intention : chaque animation doit avoir un but clair (guider, confirmer une action, expliquer une fonctionnalité) et ne pas alourdir l’expérience utilisateur. Les interfaces les plus efficaces sont celles qui se font oublier, en minimisant les frictions. L’auteur souligne l’importance de la performance perçue (idéalement sous 300 ms par animation), du respect des préférences utilisateur (comme l’option « réduire les animations »), et de l’inclusivité, notamment pour les personnes neuroatypiques. L’objectif ? Créer des expériences calmes, prévisibles et accessibles, où le mouvement sert l’utilisateur sans le distraire. Une question clé à se poser : « Pourquoi cette animation ? »—et si la réponse est « juste pour faire joli », mieux vaut s’en passer.

Dans ce billet, l’auteur souligne que les équipes de développement évoluent constamment avec les arrivées et les départs de membres, ce qui crée à chaque fois une nouvelle dynamique d’équipe. Ces changements entraînent des pertes de connaissances non documentées ou des décisions implicites, mais aussi l’apport de nouvelles perspectives. Pour atténuer les perturbations, il est crucial d’avoir une documentation claire, une vision partagée et des standards de développement bien définis (architecture, choix techniques, processus de revue de code, stratégie de tests, etc.). Ces éléments permettent de maintenir une cohérence et une direction commune, même lorsque la composition de l’équipe change. L’idéal serait d’automatiser cette documentation pour qu’elle reste toujours à jour et accessible, assurant ainsi la stabilité du projet sur le long terme.

L’article explore comment les URLs, souvent sous-estimées, peuvent servir de conteneurs de state puissants et élégants dans les applications web modernes. L’auteur illustre ce concept avec l’exemple de PrismJS, où une URL encode toute la configuration (thème, langages, plugins) de manière partageable et récupérable, sans base de données ni stockage local. Il rappelle que les URLs offrent gratuitement des fonctionnalités clés : partage, marquage, historique, et liens profonds. L’article détaille comment structurer les URLs (segments de chemin, paramètres de requête, fragments) pour y stocker des états comme des filtres, des préférences ou des configurations, tout en évitant les pièges (données sensibles, états temporaires, surcharge). Des exemples concrets (GitHub, Google Maps, Figma) montrent leur utilité, et des bonnes pratiques (utilisation de URLSearchParams, gestion des défauts, debounce) sont proposées pour une implémentation efficace, notamment avec JavaScript ou React. Enfin, l’auteur souligne que les URLs bien conçues agissent comme des contrats clairs entre l’application et ses utilisateurs, améliorant l’expérience et la performance. Une lecture essentielle pour repenser la gestion d’état côté frontend

Cet article donne un exemple de bouton HTML invalide, et explique comment fixer ses problèmes.

Il s'agit d'un article pratique sur l’art de nommer les éléments en PHP. L’auteure y aborde l’importance des noms clairs dans le code, soulignant qu’ils réduisent la charge cognitive, améliorent la maintenabilité et facilitent l’onboarding des nouveaux développeurs. L’article propose des principes concrets, des conventions compatibles avec les PSR, et des exemples pour éviter les pièges courants liés à la liberté syntaxique de PHP (comme les tableaux dynamiques ou les objets flexibles). L’objectif ? Transformer le choix des noms en un processus réfléchi plutôt qu’en devinette, pour un code plus lisible et une architecture plus robuste.

Article réservé aux membres Medium.

Linus Torvalds illustre ici ce qu’il considère comme du « garbage code » : des abstractions inutiles qui alourdissent la compréhension du code, comme une fonction make_u32_from_two_u16(a,b) qui masque la simplicité et la clarté de l’opération (a << 16) + b. Son argument central : le bon code optimise la charge cognitive. Chaque abstraction ou fonction helper impose un coût en termes de contexte (pour les humains comme pour les LLMs), car elle nécessite de « sauter » mentalement vers une autre partie du code, ce qui consomme de l’énergie et augmente le risque d’erreurs. Parfois, la duplication ou l’écriture explicite est préférable à une abstraction prématurée, surtout si celle-ci ne clarifie pas le code ou n’est pas réutilisée massivement. Torvalds rappelle aussi que le coût de la duplication a diminué avec les outils modernes de refactoring. Enfin, l’article souligne l’importance de la bienveillance dans les revues de code, même si le fond du message de Linus reste pertinent : privilégier la lisibilité et la localité du code.

Eugene Yan partage ses conseils pour les nouveaux Principal Engineers (ou ICs - contributeurs individuels - techniques principaux), inspirés de ses observations et de mentors, notamment dans un contexte Amazon. Il souligne que le rôle varie selon les profils : certains excellent dans la technique pure, d’autres dans l’influence transversale ou l’alignement d’équipes. À ce niveau, le codage devient secondaire ; l’impact passe par la vision technique, le mentorat, la connexion des équipes et la résolution de problèmes ambigus que personne d’autre ne traite. Le Principal Engineer doit aussi savoir convaincre, déléguer, et créer de l’espace pour les autres, tout en évitant de devenir un goulot d’étranglement. L’article insiste sur l’importance de rester "hands-on" ponctuellement, de clarifier le "pourquoi" derrière les décisions, et de se préserver des réunions inutiles pour garder du temps de réflexion stratégique. Enfin, il rappelle que ce poste exige une autonomie totale dans le choix des problèmes à résoudre, avec une responsabilité accrue envers l’organisation et soi-même. Une lecture utile pour comprendre les attentes et défis de ce rôle clé en ingénierie.

En 2025, jQuery reste largement utilisé, surtout pour la maintenance de projets legacy, où le coût et les risques d’une migration vers des frameworks modernes ne justifient pas les bénéfices. L’article souligne aussi son utilité pour le prototypage rapide, la manipulation DOM complexe dans des environnements multi-navigateurs, ou encore les animations et requêtes AJAX simples. Cependant, pour les applications modernes, et ciblant uniquement les navigateurs récents, jQuery n’est plus pertinent : les API natives (comme fetch, querySelector) et les frameworks (React, Vue) offrent des alternatives plus légères et mieux adaptées. L’auteur conclut que jQuery reste un outil valable pour certains cas d’usage, mais qu’il faut savoir choisir la bonne technologie selon le contexte.

Cet article présente une approche pragmatique pour construire une application SaaS multi-tenant avec Symfony, en utilisant une base de données partagée et une seule codebase pour plusieurs clients (tenants). L’article s’appuie sur l’expérience de l’auteur, qui a développé une plateforme pour des marques de retail, chacune ayant ses propres magasins, utilisateurs et règles d’accès.

Points clés :

• Résolution du tenant : Identification du client actif via la session (back-office) ou le sous-domaine (front-office), stockée dans un service TenantContext accessible partout dans l’application.
• Isolation des données : Toutes les entités liées à un client incluent un brand_id, et les requêtes sont automatiquement filtrées par ce contexte.
• Contrôle d’accès (ACL) : Gestion des fonctionnalités et permissions par client via des listes de contrôle d’accès (ACL) et des voters Symfony, permettant d’activer/désactiver des fonctionnalités par marque.
• Architecture unifiée : Le même TenantContext est utilisé pour le back-office (session) et le front-office (domaine), garantissant une cohérence et une sécurité optimale.

L’article insiste sur la simplicité, la maintenabilité et l’évolutivité de cette solution, idéale pour les SaaS nécessitant une isolation des données sans complexité infrastructurelle.

L’article explique comment concevoir des tableaux clairs et efficaces, en s’appuyant sur les travaux d’Edward Tufte et de Charlie Munger. Il souligne que le choix entre tableau et graphique dépend de l’usage : les tableaux conviennent mieux aux petits jeux de données et aux comparaisons précises, tandis que les graphiques mettent en valeur les tendances et le mouvement des données. Pour rendre un tableau lisible, il recommande de limiter les bordures et les couleurs, d’aligner correctement le texte et les nombres (à droite pour ces derniers), et d’éviter les répétitions inutiles. L’article propose aussi des bonnes pratiques en HTML/CSS pour structurer et styliser les tableaux, comme l’utilisation de <thead>, <tbody>, et <tfoot>, l’alignement vertical sur la baseline, et l’adaptation responsive pour mobile. Enfin, il insiste sur l’importance de maximiser le ratio "data-ink" (encre utile) et de supprimer tout élément redondant ou superflu pour faciliter la compréhension. Une référence utile pour quiconque souhaite améliorer la présentation de données.

Cet article remet les pendules à l'heure : Postman et consorts ne servent à rien... puisque cURL fait tout ce qu'ils font en plus rapide et léger. L'article rappelle les options à passer pour les principaux cas d'usage : requêtes POST, ajout d'entêtes, upload de fichiers, cookies, authentification basique / OAuth / etc.
Pour le partage, tout peut s'écrire dans des scripts versionnables.

L’article raconte une expérience douloureuse : l’utilisation du tag latest pour une image Docker a causé une panne en production après qu’une mise à jour silencieuse de l’image de base (PostgreSQL) ait changé la version de collation du système d’exploitation, rendant la base de données incompatible. L’auteur explique que latest n’est pas synonyme de « stable » ou « sûr », mais simplement de « dernière version disponible », ce qui peut varier à tout moment. Il détaille trois raisons d’éviter latest : stabilité (comportement cohérent), reproductibilité (diagnostic et audit facilités), et contrôle des mises à jour (éviter les surprises). La solution ? Toujours spécifier un tag explicite (ex: postgres:15.3-alpine) dans Docker, Docker Compose ou Kubernetes. Un rappel utile : ne jamais laisser le choix de la version à quelqu’un d’autre, surtout en production.

Les fichiers .http offrent une alternative légère et efficace aux outils comme Postman pour tester et documenter des APIs directement depuis un éditeur de code. Ces fichiers texte, basés sur la syntaxe HTTP standard, permettent de décrire, versionner et exécuter des requêtes HTTP sans dépendre d’un outil externe ou d’un compte cloud. Intégrés nativement dans des IDE comme VS Code (via l’extension REST Client) ou JetBrains, ils facilitent le versionnement avec Git, la collaboration via des pull requests, et servent de documentation vivante pour les APIs. Leur simplicité et leur indépendance technologique en font un choix idéal pour les équipes souhaitant éviter les outils lourds et centraliser leurs tests d’API dans leur repository. L’article propose des exemples concrets avec les APIs publiques françaises (comme l’API Geo et Adresse), montre comment gérer les variables et environnements, et explique comment automatiser ces tests dans des pipelines CI/CD avec des outils comme httpyac. Une solution pragmatique pour les développeurs cherchant à simplifier leur workflow tout en gardant une documentation et des tests à jour.