Parcourez tous les articles dans cette catégorie
La base de données de production est tombée vendredi à 18h. Le post-mortem a eu lieu lundi. Dans le compte-rendu : cinq points d'amélioration des processus, trois actions de remédiation technique, et une mention discrète que 'l'incident a été causé par une erreur humaine lors de la migration'. Cette phrase est l'opposé d'un blameless post-mortem.
Si votre équipe passe plus de temps à débattre de monorepo vs polyrepo qu'à écrire du code, c'est le signe que le débat est mal posé. Les deux approches fonctionnent. La vraie question est : quelle structure correspond à votre organisation et à votre cycle de livraison ?
Votre codebase a 47 feature flags actifs. Cinq sont documentés. Trois sont liés à des fonctionnalités livrées il y a neuf mois et personne n'a pensé à les supprimer. Deux sont conflictuels : activer les deux en même temps produit un comportement indéfini. Vous venez de découvrir pourquoi les feature flags ne sont pas gratuits.
L'équipe a passé trois semaines à modéliser les bounded contexts, les aggregates et les domain events de son application de gestion de contenu. L'application fait du CRUD sur cinq tables. C'est le signe que DDD est utilisé comme fin en soi, pas comme outil.
« On a besoin d'un sprint de dette technique. » Cette phrase est prononcée dans des centaines d'équipes chaque trimestre. Ce qui se passe ensuite : deux semaines de refactorisation sans direction claire, dont la valeur est impossible à communiquer au management, et qui ne change pas fondamentalement les problèmes les plus douloureux.
Combien de jours un nouveau développeur passe-t-il à essayer de faire tourner le projet en local avant de pouvoir contribuer réellement ? Dans la plupart des équipes, la réponse est entre deux et dix jours. La documentation d'onboarding existe, elle est juste fausse.
Combien de fois avez-vous vu une release se transformer en fourre-tout de fonctionnalités semi-terminées, de corrections de dernière minute et de tickets migrés depuis trois sprints précédents ? La release a perdu son sens parce qu'elle n'est utilisée que comme conteneur de livraison, pas comme outil de pilotage.
La complexité se construit facilement. La simplicité se choisit. KISS n'est pas une paresse intellectuelle : c'est une discipline qui exige de résister à l'envie d'ajouter, d'intégrer, d'adopter tout ce qui brille.
Combien d'heures de votre vie avez-vous passé à implémenter un algorithme de tri à bulles pour un poste où vous allez passer vos journées à faire des appels REST et à déboguer des requêtes SQL ? Le recrutement tech s'est transformé en obstacle course qui ne mesure rien d'utile.
Il n'existe pas de domaine professionnel où les fondamentaux se périment aussi vite qu'en développement logiciel. Cette réalité génère un état d'âme particulier, mélange de FOMO chronique et de sentiment d'impuissance. Voici comment en sortir.
Travailler avec l’IA promet une merveille : développer plus rapidement. Et c’est vrai. Les lignes de code s’écrivent plus vite, les fonctionnalités prennent forme en heures au lieu de jours. Mais cette promesse cache un prix invisible, souvent ignoré ou minimisé : la perte progressive de maîtrise.
Nous célébrons le gain en vitesse. Cinq fonctionnalités écrites en une semaine au lieu de trois, c’est chiffrable. Quantifiable. Mais comment mesure-t-on la perte de maîtrise ? Comment comptabilise-t-on ce qu’on ne comprend plus vraiment ?
