Cto

Inspiré du chapitre “Les nouvelles attentes des recruteurs” du livre “En quête d’expérience”. Dédramatisation “Excellent techniquement mais…” Cette phrase, je l’ai entendue cent fois en entretiens de débriefing. Le “mais” tue plus de carrières que les bugs. Mais ce n’est pas une fatalité. Les soft skills ne sont pas des talents innés, ce sont des compétences qui se développent avec la pratique. Ce que j’ai observé : en 2025, maîtriser React ne suffit plus. Le marché valorise de plus en plus la collaboration et la communication. Mais cela ne signifie pas que vous devez être extraverti ou charismatique. Les soft skills techniques (communication claire, empathie, écoute active) sont différentes des soft skills sociales générales. ...

Article inspiré du chapitre “Le marché 2025” du livre “En quête d’expérience”. Dédramatisation En 2020, ces trois métiers n’existaient pas vraiment. En 2025, ils recrutent à tour de bras avec des salaires parfois supérieurs aux seniors classiques. Mais ce ne sont pas des modes passagères. Ils résolvent de vrais problèmes : Prompt Engineering (industrialiser l’IA), MLOps (ML en production scalable), Cloud Security (protéger assets cloud). Ce que j’ai observé : beaucoup de développeurs sont tentés par ces nouveaux métiers pour les salaires (+25% à +35% vs développeur Full-Stack), mais ils ignorent les compétences requises et les risques (hype bubble potentielle, nécessité double compétence, on-call rotation). Ces métiers nécessitent un investissement en temps et en apprentissage. Est-ce pour vous ? Posez-vous : ai-je l’appétit d’apprendre un domaine nouveau ? Suis-je OK avec évolution rapide du métier ? Les salaires justifient-ils l’investissement temps ? ...

Situation réelle “Il faut 100% de couverture de tests !” vs “Les tests, c’est une perte de temps !”. Entre ces deux extrêmes, où se trouve la vérité ? Après avoir vu des projets paralysés par des suites de tests trop lourdes et d’autres s’effondrer faute de tests, j’ai trouvé quelques équilibres pragmatiques. Ce que j’ai observé : les tests ne sont pas une religion, c’est un outil. Et comme tout outil, ils doivent être adaptés au contexte du projet et aux contraintes de l’équipe. Une stratégie de test efficace n’est pas celle qui a 100% de couverture, c’est celle qui donne confiance à l’équipe pour livrer rapidement sans casser l’existant. Les meilleurs tests sont ceux qu’on oublie : ils tournent en arrière-plan, attrapent les bugs avant la production, et ne ralentissent pas le développement. ...

Situation réelle La croissance rapide d’une startup est souvent vue comme un problème enviable. Pourtant, derrière chaque succès se cachent des défis techniques majeurs qui peuvent transformer ce rêve en cauchemar opérationnel. Ce que j’ai observé : au fil de mes missions d’audit technique, j’observe des patterns récurrents. Les mêmes problèmes, les mêmes solutions d’urgence, les mêmes conséquences. Ces défis ne sont pas le fruit d’incompétence, mais plutôt de contraintes inhérentes à l’environnement startup où la vitesse prime souvent sur la robustesse. La croissance technique n’est pas qu’une question de volume, c’est un changement qualitatif profond. ...

Situation réelle “L’IA va remplacer les développeurs !” Cette phrase, je l’entends depuis novembre 2022. Trois ans plus tard, je suis toujours développeur. Et vous aussi probablement. Ce que j’ai observé : l’IA accélère, elle ne remplace pas. Avant (2020) : 2h de recherche StackOverflow, copier-coller 5 solutions, adapter pendant 30min, total 2h30. Maintenant (2025) : prompt ChatGPT “Implémenter OAuth2 avec refresh token”, code généré en 30 secondes, review et adaptation 15min, total 20min. Gain de temps réel : 85%. ...

Dédramatisation “Software Craftsmanship”, “Clean Code”, “SOLID”… Ces termes circulent partout dans notre écosystème, souvent accompagnés d’un sentiment d’intimidation. J’ai longtemps pensé que c’était réservé aux développeurs “experts”, à ceux qui écrivent des livres ou donnent des conférences. Erreur ! Le Software Craftsmanship, c’est avant tout une démarche progressive d’amélioration continue. Pas besoin d’être Robert C. Martin pour commencer. Il suffit de faire un pas, puis un autre. Le Software Craftsmanship n’est pas une destination, c’est un voyage. Chaque petit pas compte : un nom de variable plus clair, une fonction mieux découpée, un test ajouté. ...

Situation réelle “Alice démissionne.” Première réaction : panique, sentiment d’échec, culpabilité. Puis parfois : colère, sentiment de trahison. Ces émotions sont humaines mais ne doivent pas dicter la réponse. Ce que j’ai observé : un départ bien géré peut renforcer la culture. Un départ mal géré peut détruire la confiance de ceux qui restent. Le faux problème Le faux problème serait de croire qu’un départ est toujours un échec. En réalité, les gens évoluent, changent de trajectoire, et c’est normal. Certains départs sont même sains. ...

Situation réelle “Pourquoi ce bouton est-il différent sur cette page ?” Cette question, tout développeur frontend l’a déjà entendue. Et derrière cette apparente broutille se cache un problème plus profond : l’absence de référentiel commun entre les équipes design et développement. Ce que j’ai observé : après avoir participé à la mise en place de plusieurs Design Systems, je peux affirmer que leur valeur dépasse largement la cohérence visuelle. Ils transforment la façon dont les équipes collaborent et accélèrent significativement les cycles de développement. Sur un projet récent, nous avons mesuré un gain de 40% sur le temps de développement des interfaces après implémentation du Design System. Les développeurs passaient moins de temps sur le styling et plus sur la logique métier. ...

Situation réelle “L’équilibre pro-perso est important ici.” Puis : Slack à 23h du manager. Valorisation de qui fait 60h/semaine. Culpabilisation de qui part à 18h. L’écart entre discours et réalité détruit la crédibilité. Ce que j’ai observé : l’équilibre se mesure aux comportements réels, pas aux valeurs affichées. Ce que le leadership fait compte plus que ce qu’il dit. Le faux problème Le faux problème serait de croire qu’il suffit d’afficher la valeur. En réalité, sans incarnation par le leadership et sans garde-fous structurels, ça reste cosmétique. ...

Situation réelle “Il nous faut des microservices !” Cette phrase revient régulièrement lors des revues d’architecture. Souvent prononcée avec la certitude que cette approche résoudra tous les problèmes d’évolutivité et de performance. Mais après avoir conçu et maintenu des systèmes dans les deux paradigmes, je peux affirmer que la réalité est bien plus nuancée. Ce que j’ai observé : le choix entre microservices et monolithe modulaire ne devrait jamais être dicté par la mode technologique, mais par des critères objectifs liés au contexte du projet. Chaque approche a ses avantages et ses inconvénients. L’important est de comprendre quand chaque approche fait sens. ...