L'article explore une approche proactive pour intégrer la performance web dès le début du développement, évitant ainsi le cycle de dégradation des performances. Odell, ingénieur chez Canva, propose d'impliquer toute l'équipe et de rendre la performance visible tôt, plutôt que de la traiter comme un problème à résoudre a posteriori. Il explique comment les problèmes de performance s'accumulent silencieusement et pourquoi les corrections tardives sont souvent inefficaces. La solution proposée est de créer des systèmes et des processus qui favorisent naturellement les décisions rapides et performantes.
L'article souligne l'importance cruciale de l'attribut lang dans la balise <html> pour l'accessibilité web. Cet attribut indique la langue du contenu aux navigateurs et lecteurs d'écran, évitant ainsi des erreurs de prononciation et améliorant l'expérience utilisateur pour les personnes malvoyantes ou dyslexiques. Malgré son importance, l'omission de cet attribut reste un problème récurrent, comme le montre le rapport WebAIM Million. L'auteur insiste sur la nécessité d'une meilleure éducation en accessibilité pour les développeurs.
L'article explique comment associer explicitement des éléments HTML, comme les labels et les champs de formulaire, en utilisant des IDREFs. Il souligne l'importance de cette pratique pour améliorer l'accessibilité, notamment pour les technologies d'assistance. L'auteur détaille les bonnes pratiques, telles que l'unicité et l'existence des IDs, et propose des outils pour détecter les références brisées. Un exemple concret illustre l'utilisation de l'attribut for dans une balise <label> pour référencer l'ID d'un champ <input>.
Cet article explique comment rédiger un bon fichier CLAUDE.md pour optimiser l'utilisation de l'IA Claude dans un projet de code. Il souligne que les modèles de langage (LLMs) sont sans état et ne connaissent rien du codebase au début de chaque session, d'où l'importance de CLAUDE.md pour les informer. Le fichier doit couvrir le "quoi", le "pourquoi" et le "comment" du projet, mais sans surcharger d'informations non pertinentes, car Claude pourrait les ignorer. Des conseils pratiques sont donnés pour créer un fichier efficace, en suivant les bonnes pratiques d'ingénierie de contexte.
Ce guide pratique de l'OWASP Top 10, destiné aux développeurs web, détaille dix erreurs courantes et comment les éviter. Il aborde des sujets comme le contrôle d'accès brisé (A01), les échecs cryptographiques (A02), et les injections (A03), avec des exemples concrets et des solutions pour les prévenir dès l'écriture du code. Un outil précieux pour améliorer la sécurité des applications web.
Dans ce 3ᵉ et dernier volet de sa série, l’auteur raconte comment il a concrètement « vibe codé » une CLI — une petite application génératrice de Cilium Network Policies — en utilisant Claude Code et Speckit. Au-delà de la phase initiale d’idéation et de conception (décrite dans les épisodes précédents), ce billet détaille comment, à travers un workflow rigoureux (spécification, clarification, planification, découpage en tâches, validation, générations de code et tests), l’auteur a transformé un besoin métier complexe en un MVP fonctionnel — livré en un seul sprint et déjà en production. Il en tire des leçons fortes : l’IA ne remplace pas le développeur, elle l’augmente, mais uniquement si on encadre l’exercice avec une méthode claire, des specs précises et une boucle de validation humaine. Pour finir, il plaide pour une évolution du rôle du développeur vers celui d’architecte / Product Owner — capable de piloter l’IA tout en garantissant la qualité, la cohérence et la maintenabilité du code.
L'article met en garde contre la sur-ingénierie et l'utilisation excessive de motifs de conception complexes dans des projets qui ne le nécessitent pas. L'auteur illustre son propos avec un exemple extrême où une simple concaténation de chaînes de caractères est transformée en une architecture complexe impliquant des interfaces, des usines et des modules. Il identifie plusieurs drapeaux rouges, comme la "future-proofing" fallacieuse, les interfaces avec une seule implémentation, et les abstractions prématurées. L'auteur propose une checklist pour évaluer la nécessité d'une abstraction et encourage à supprimer les mauvaises abstractions. Il conclut en rappelant que le code "scalable" ne doit pas être surestimé et que la simplicité est souvent la clé.
Nicolas Jourdan explique comment créer des commandes personnalisées pour Symfony Console de manière professionnelle avec Symfony 7.4. L'article montre l'évolution des bonnes pratiques en partant d'une approche classique, puis en introduisant les commandes invocables et les attributs d'entrée pour un code plus propre et plus lisible. L'exemple concret d'une commande pour importer des avis clients depuis un fournisseur externe illustre ces améliorations.
L’auteur montre comment un service « simple » qui orchestre plusieurs effets secondaires (sauvegarde, envoi d’e-mail, tracking analytics…) peut sembler propre et fonctionner en développement — mais devient une « bombe à retardement » en production : latence, états partiels incohérents, logique métier mélangée à l’orchestration. Comme solution, il recommande d’introduire d’abord des Domain Events pour découpler la logique métier des effets secondaires, puis d’utiliser le pattern Outbox pour garantir l’atomicité entre la persistance des entités et des événements, et enfin — lorsque les étapes sont critiques (paiement, création de wallet, etc.) — d’opter pour un pattern Saga pour assurer soit la réussite de l’ensemble, soit la compensation en cas d’échec.
Ce guide explique comment implémenter la validation dans une architecture Domain-Driven Design (DDD) en suivant une approche par couches. Il souligne l'importance de maintenir l'intégrité des objets de domaine, de valider uniquement ce pour quoi chaque couche est responsable, et d'éviter la duplication de la logique de validation. L'article détaille les meilleures pratiques pour la validation dans la couche de domaine (objets de valeur, entités et services de domaine) et la couche d'application (validation des commandes et orchestration des cas d'utilisation). Il met en avant l'importance de fournir des messages d'erreur clairs et de valider rapidement.
Ahmad Bilal partage 50 erreurs courantes en TypeScript pour éviter les pièges et améliorer la qualité du code. L'article explique comment TypeScript, bien que prometteur, peut donner une fausse impression de sécurité si mal utilisé. Il couvre des erreurs basiques (comme l'utilisation abusive de any ou l'ignorance des avertissements du compilateur) et des pièges plus avancés (comme la confusion entre null et undefined ou l'oubli du type never). Un guide pratique pour mieux maîtriser TypeScript.
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.