L’article souligne que le Domain-Driven Design (DDD) gagne en importance avec l’essor de l’IA générative, car cette dernière simplifie la partie technique du développement, mais ne remplace pas la nécessité de bien comprendre et modéliser le domaine métier. L’auteur, Miłosz Smółka, rappelle que le DDD, popularisé par Eric Evans en 2003, reste pertinent car la complexité centrale des projets logiciels réside dans la résolution des problèmes métiers, et non dans les détails techniques.
L’IA permet désormais de générer du code rapidement, réduisant l’importance des frameworks et des langages, mais elle ne peut pas remplacer le travail collaboratif entre experts métiers et développeurs pour construire un modèle précis. Le DDD insiste sur la knowledge crunching (affinage des connaissances) et des méthodes comme l’Event Storming pour capturer la logique métier, des étapes que l’IA ne peut automatiser entièrement.
Enfin, l’article met en garde contre la tentation de confier la modélisation du domaine à l’IA, soulignant que cette tâche reste un effort collectif et itératif. L’optimisation des outils d’IA pour générer du code doit s’accompagner d’une focalisation accrue sur la compréhension du domaine, sous peine de reproduire les erreurs passées où la technologie était privilégiée au détriment du problème à résoudre.
Chez Elao, l’article souligne le manque de collaboration entre designers et développeurs, souvent dû à des formations cloisonnées et à des outils incompatibles. Les designers, formés pour l’expérience utilisateur, négligent parfois la dimension technique des maquettes, tandis que les développeurs peinent à interpréter les livrables visuels. Pour y remédier, l’entreprise a intégré Storybook comme référence partagée, facilitant la communication et réduisant les itérations de correction. Cette approche vise à aligner les processus et à accélérer le développement des projets.
L’article explore les défis méconnus des équipes d’ingénierie réparties à l’international. Basé sur son expérience chez Getaround, il révèle que les fuseaux horaires réduisent significativement la productivité, malgré les avantages théoriques (24/7 développement, accès à plus de talents). Les équipes locales restent plus efficaces, et les solutions comme les outils async ne compensent pas la perte de collaboration en temps réel. L’auteur, ayant géré des équipes acquises à l’étranger, prône des équipes regroupées géographiquement (3-5h max de décalage) pour faciliter l’intégration et les relations humaines, surtout après des fusions. Un constat sans appel : mieux vaut limiter les dégâts que prétendre à une performance optimale en global.