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’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.
Sean Goedecke y explique que le bon design système repose sur la simplicité, la minimisation de l’état (state) et l’utilisation judicieuse de composants éprouvés (bases de données, caches, files d’attente, etc.). Un bon design se remarque surtout par son absence de problèmes et sa discrétion : si tout fonctionne sans accroc et semble plus simple que prévu, c’est souvent signe de réussite. L’auteur insiste sur l’importance de centraliser la gestion de l’état (via une base de données bien structurée et indexée), d’éviter la complexité inutile, et de privilégier des solutions robustes plutôt que des astuces sophistiquées. Les opérations lentes doivent être déléguées à des tâches en arrière-plan, et le cache utilisé avec parcimonie. Enfin, il souligne que les "hot paths" (chemins critiques) méritent une attention particulière, tout comme la journalisation et la gestion des échecs (killswitches, retries). En résumé, un bon design système est souvent invisible, mais efficace et maintenable sur le long terme.
L'article explore les concepts fondamentaux de la conception de systèmes, essentiels pour les développeurs et les ingénieurs logiciels. Il aborde des sujets variés tels que l'architecture client-serveur, les adresses IP, le DNS, les proxys, la latence, les protocoles HTTP/HTTPS, les APIs, les bases de données SQL et NoSQL, ainsi que des techniques de mise à l'échelle comme le scaling vertical et horizontal, l'équilibrage de charge, l'indexation des bases de données, la réplication et le sharding. L'article vise à simplifier ces concepts pour les rendre accessibles, que ce soit pour des entretiens techniques ou pour la conception de systèmes scalables dans un environnement professionnel.
Dans son article, Lea Verou présente le framework "Hovercar", une approche innovante pour le développement de produits qui suggère de commencer par la vision finale plutôt que par un produit minimum viable (MVP). Contrairement à la méthode traditionnelle qui privilégie le démarrage à petite échelle, Verou propose de visualiser d'abord le produit final idéal, appelé "North Star UI", pour guider la conception et le développement. Cette vision sert de boussole pour orienter les décisions de conception et s'assurer que chaque étape du processus contribue à atteindre cet objectif ultime, tout en différenciant clairement cette approche de la "North Star Metric", qui est plutôt utilisée pour évaluer le succès d'un produit.
Un article très intéressant dans lequel l'auteur compare 2 styles de développement (piloté par les données versus piloté par les besoins métiers), et leur relation avec l'automatisation possible ou non de process métiers.
Tout est dans le titre
Moralité : créer des composants c'est bien... mais ne jamais perdre de vue le "plan complet" de l'application dans lesquels ils s'insèrent, c'est mieux
Tout est dans le titre
Conclusion de l'article : éviter le plus possible d'employer des mots comme facile, simple, rapide, ... quand on décrit une fonctionnalité à implémenter
Tout est dans le titre
Une série très instructive - cet article est consacré à GraphQL
Un article intéressant sur la conception de produits qui marchent, avec quelques rappels historiques
Tout est dans le titre
Un article très intéressant sur la conception logicielle
Tout est dans le titre :) - excellente initiation