Parcourez tous les articles dans cette catégorie
Un développeur n'a pas besoin du titre de lead pour choisir de partager plutôt que de garder, d'assumer plutôt que de reporter, d'aider plutôt que de résoudre à la place de l'autre. Ces choix ne dépendent pas d'un poste, ils dépendent d'une décision qu'on prend chaque jour.
Un QA qui ne fait que cocher des cases de test à la fin du cycle a raté l'essentiel du poste. Le vrai travail consiste à empêcher le bug d'exister avant même qu'il ne soit écrit, et à porter la responsabilité collective quand ça échoue quand même.
Un Product Manager qui rédige des specs parfaitement détaillées sans laisser d'espace à l'équipe n'a rien compris à son poste. Le vrai travail consiste à poser les bonnes questions, assumer les mauvais paris, et laisser les autres trouver les réponses.
Un CTO qui code encore à temps plein n'a pas encore compris son poste. Le vrai travail consiste à absorber la pression du business pour que les équipes techniques puissent construire correctement, et à porter seul les décisions qui tournent mal.
Un Lead Developer qui code toute la journée n'est pas un lead, c'est un développeur avec un titre en plus. Le vrai travail est ailleurs : dans les décisions qu'on prend pour que d'autres puissent bien faire les leurs. Et ça commence par accepter de disparaître un peu.
Il est 14h. Tu viens de rentrer dans un état de concentration profonde. Ton ticket avance. Et là : une invitation de réunion pour dans dix minutes. « Rapide sync sur le sujet X. » Cette réunion aurait pu être un message.
Il est 9h30. L'équipe est réunie. Chacun à son tour répond aux trois questions : « Qu'est-ce que j'ai fait hier, qu'est-ce que je fais aujourd'hui, quels sont mes blocages. » Quinze minutes plus tard, tout le monde repart à son écran sans que rien n'ait changé. Ce daily n'a servi à rien.
Il existe dans l'industrie tech un archétype admiré : le développeur brillant et solitaire qui produit plus de code que dix développeurs ordinaires. Cet archétype influence les recrutements, justifie des packages salariaux inégaux et crée des cultures d'équipe dysfonctionnelles. Il est aussi en grande partie un mythe.
Votre organisation a implémenté SAFe. Vous avez maintenant des ARTs, des PI Plannings, des System Demos et des Inspect & Adapt workshops. Votre organisation est également plus lente, plus réunionnée et plus frustrante pour les ingénieurs qu'avant. Ce n'est pas un bug de votre implémentation SAFe. C'est souvent une caractéristique.
L'estimation est souvent une fiction partagée : les développeurs donnent des chiffres qu'ils savent imprécis, le management les prend comme des engagements, et quand les estimations sont dépassées, tout le monde est surpris d'être surpris. #NoEstimates dit : arrêtons la fiction. La question est : par quoi on la remplace ?
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.
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 eu un 1-on-1 où votre manager a ouvert Jira pour passer en revue vos tickets en cours ? Cette réunion aurait pu être un email, ou une consultation de tableau Kanban. Le 1-on-1 qui ressemble à un rapport de statut est un 1-on-1 gâché.
Votre équipe a une page Notion avec le plan du prochain trimestre. Elle a été rédigée la semaine dernière. Trois personnes ont ajouté des commentaires. Deux ont mis un emoji. Le plan n'a pas changé. Personne n'a pris de décision. C'est l'async sans contrôle : beaucoup d'activité, peu de résolution.
« Notre velocity est de 42 points par sprint. » Cette phrase est prononcée avec fierté dans des centaines de réunions de planification chaque semaine. Elle dit quoi, exactement ? Que l'équipe ferme des tickets à un rythme cohérent. Ce qu'elle ne dit pas : si ces tickets créent de la valeur, si les estimations sont réalistes, si l'équipe est épanouie.
« En tant qu'utilisateur, je veux pouvoir me connecter afin de pouvoir accéder à mon compte. » Ce ticket a été écrit des millions de fois. Il ne décrit rien d'utile sur ce que le développeur doit faire. C'est le problème central de la user story comme unité de travail.
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.
Une annonce pour un poste de développeur demande : PHP, Python, JavaScript, Java, C++, Go, Rust, SQL, HTML/CSS, et bien sûr « quelques années d'expérience avec Kubernetes ». Personne ne demande ça en médecine. Pourquoi c'est devenu normal en tech ?
On vous pose la question souvent : « Pourquoi en France, recruter, c’est comme passer des auditions pour un film de Spielberg, mais pour un CDI à 2 500 euros par mois ? »
Voici le paradoxe : en France, nous avons une législation parmi les plus protectrices en matière d’emploi. Les périodes d’essai peuvent s’étendre sur plusieurs mois. L’employeur peut légalement tester la relation avant de s’engager. Et pourtant, les startups françaises ont mis en place un parcours du combattant : 4 entretiens, 1 test technique, une vérification de références, parfois même un cas pratique à préparer chez soi.
Vous vous souvenez de 2020-2021 ? Le full remote était la promesse du futur du travail. Les entreprises découvraient soudainement que leurs employés pouvaient être productifs de chez eux. Les trajets disparaissaient. Les coûts immobiliers chutaient. Les talents pouvaient venir de n’importe où dans le monde. C’était une révolution.
Aujourd’hui, en 2026, le pendule a complètement basculé. Les offres d’emploi crient « hybride 3 jours au bureau » ou carrément « on-site only ». Les recruteurs vous demandent : « Tu peux venir au bureau, hein ? » comme si vous aviez posé une question étrange. Le full remote ? C’est devenu presque toxique de le demander.
