Concepts Sélectionnés
La communication est le travail
La gestion de produit, c'est prendre des commandes comme un serveur chez Denny's. Le design transmet une maquette. L'ingénierie la construit sans la comprendre. Les utilisateurs rient d'abord, puis disent maladroitement, "Oh, c'est ça que vous avez construit ?" Chacun pointe du doigt quelqu'un d'autre. Les membres de l'équipe résolvent des problèmes différents dans leur tête, et personne ne s'est arrêté pour confirmer qu'ils construisent la bonne chose.
La maîtrise du domaine est le multiplicateur
Un ingénieur propose de montrer aux passagers à quel point leur bus est "en retard". Les responsables des échanges de regards : "Savez-vous ce qu'est un service basé sur l'intervalle ?" Il ne le sait pas. Il construit des logiciels de transport depuis un an sans apprendre que les routes à haute fréquence n'ont pas d'horaire significatif. Sa fonctionnalité afficherait des absurdités à des centaines de milliers de passagers. La compétence technique ne signifie rien si vous résolvez le mauvais problème.
La découverte fait gagner du temps
Les équipes disent qu'elles n'ont pas le temps pour la découverte, puis trouvent d'une manière ou d'une autre le temps pour les retouches. Elles livrent une fonctionnalité que personne n'utilise, corrigent les cas limites que personne n'a demandés, et appellent cela "itération". Ce n'est pas un biais en faveur de l'action. C'est la peur que réfléchir ressemble à ne rien faire, alors elles livrent quelque chose.
Le modèle d'IA est un stagiaire enthousiaste, pas le décideur
Les assistants IA génèrent du code plausible rapidement. Ils n'ont aucune idée de savoir s'il s'adapte à votre système. Une étude de 2025 a donné aux développeurs expérimentés des outils d'IA pour des tâches réelles : ils étaient 19 % plus lents en moyenne. Pourquoi ? Ils ont accepté de mauvaises suggestions sans les examiner, suivi des chemins de code cassés, et passé plus de temps à se remettre des erreurs de l'IA qu'ils n'en ont économisé. Ne livrez jamais ce que vous n'avez pas vérifié vous-même.
Le théâtre Agile ne livre rien d'important
Les cérémonies existent. Les artefacts sont là. Mais les contraintes sont imposées de haut en bas. Le tableau dit "Terminé" lorsque les fonctionnalités n'ont pas quitté les tests. La rétrospective produit des actions que personne ne suit. La vélocité augmente tandis que le produit stagne. Les ingénieurs perdent confiance. Les parties prenantes obtiennent une image déformée. Les utilisateurs continuent d'attendre que les anciens bogues soient corrigés. Le véritable Agile réduit le risque grâce à des retours rapides. Le théâtre Agile n'est que du travail simulé.
L'ignorance de l'infrastructure crée des pannes inexpliquées
Le code était correct. Un conteneur manquait de mémoire. Le disque était plein. La base de données a atteint une limite de connexion. De l'extérieur : comportement capricieux et délais d'attente étranges. Sans un modèle mental de la façon dont les requêtes circulent du DNS au répartiteur de charge, à l'application, à la base de données, vous devinez. Même si vous êtes dans une organisation où "on jette par-dessus la clôture", vous devez comprendre l'infrastructure qui exécute votre code.
L'estimation met en lumière les risques, pas les délais
Une estimation est une prévision, pas un contrat. Le point n'est pas la précision. C'est amener l'équipe sur la même page pour que le sprint ne s'effondre pas sous un poids que personne n'a vu venir. Lorsqu'une personne dit "un point" et une autre dit "cinq points", arrêtez-vous. Cet écart est plus précieux que le nombre. Les grandes estimations sont des avertissements : le travail peut avoir besoin d'être divisé, l'objectif peut être vague, ou il y a une dépendance que tout le monde prétend ne pas exister.
Le travail invisible mène à des promotions inexistantes
Beaucoup de travail qui prouve que vous opérez à un niveau supérieur n'apparaît jamais dans les rapports de sprint : encadrer les nouveaux employés, stabiliser un système capricieux, écrire le manuel d'exploitation qui sauve le week-end de tout le monde. Dans de nombreuses organisations, si vous ne créez pas d'artefacts — documents de conception dont vous êtes l'auteur, diagrammes architecturaux, post-mortems d'incidents où vous avez dirigé la réponse — ce travail n'a pas eu lieu. Le comité de promotion ne peut pas évaluer ce qu'il ne peut pas voir.
Le travail à distance est un échange, pas une échappatoire
Vous n'avez pas de trajet, plus de contrôle et de flexibilité dans votre journée. En retour, votre équipe a besoin de fiabilité, de visibilité et de réactivité. Se déconnecter pendant deux heures à 10 h sans dire à personne n'est pas de la flexibilité. Lorsque vous disparaissez régulièrement en milieu de journée sans signal, les gens cessent de vous faire confiance pour tout ce qui est sensible au temps. Cette confiance, une fois perdue, est difficile à reconstruire.Guide du Génie Logiciel © 2026Un guide complet sur les principes du génie logiciel, les meilleures pratiques et les outils pour les développeurs modernes.