Il y a 2 ans, j'ai accepté une mission que j'aurais dû refuser. Le client voulait de l'IA. Pas de data propre. Pas d'infrastructure. Pas de vraie compréhension du besoin. J'ai dit oui quand même. Parce que c'était rentable sur le papier. Parce que je voulais prouver qu'on pouvait livrer. Parce que j'ai cru qu'on pourrait compenser le flou par l'expertise. Résultat ? 6 mois de frustration. Un consultant que j’estime usé, jusqu’à l’os. Un projet qui n'a mené nulle part. Ce jour-là, j'ai tracé mes lignes rouges. (Au stylo. Sur papier. Pour ne plus jamais les oublier.) Aujourd'hui, je refuse systématiquement certaines missions. Même quand c'est rentable. ➡️ les missions "body shopping" → quand un client veut juste une paire de mains à l'heure sans vision du livrable. Je refuse de transformer mes consultants en pièces détachées. ➡️ les profils maquillés → "Tu peux me présenter ton junior comme un senior ?" Non. C'est le mensonge structurel du secteur et je ne veux pas en faire partie. ➡️ Les missions sans alignement technique → si je sens qu'on va envoyer quelqu'un sur une stack qu'il va découvrir juste pour facturer, je dis non. Même si ça veut dire perdre du CA. ➡️ Les projets pompiers → quand un client cherche du conseil en mode panique totale sans vouloir comprendre les causes profondes. On devient alors juste un pansement sur une jambe de bois. Les missions où l'échec est programmé dès le budget. Mon refus n'est pas un jugement. C'est une question d'alignement. Pour protéger mes consultants d'un burn programmé. Pour protéger mes clients d'un échec qu'ils ne voient pas venir. Pour préserver ce qui compte vraiment : la crédibilité et l'impact réel. Parce que le CA à court terme ne vaut pas la crédibilité à long terme. Et qu'un projet pourri, ça use tout le monde. Sans exception. Dire non, c'est aussi un service.

J’ai vu un lead dev brillant se cramer en 6 mois. Voici pourquoi l'expertise seule ne sauve jamais. Il s'appelait Paul. (Prénom changé, évidemment.) Le genre de profil qu'on envoie chez un client en mode "lui, il va tout débloquer". Et techniquement ? Il cartonnait. Sauf qu'au bout de 6 mois, il était cramé. Pas parce qu'il ne savait pas faire. Mais parce qu'il absorbait toutes les merdes du projet. Parce qu'il prenait sur lui les décisions qu'il n'avait pas choisies. Parce qu'il était devenu irremplaçable donc piégé. Et le client ? Totalement dépendant. Quand Thomas a craqué, tout s'est effondré. Ce que j’ai compris ce jour là. Un expert isolé, c'est : → Des silos de connaissance qui bloquent tout le monde. → Un mec qui finit par porter ce qui dépasse son mandat. → L'alibi technique qu'on envoie rassurer un COMEX sans les moyens réels de peser sur les décisions. Ce n’est pas une question de compétence. C'est une question de cadre. Un projet tient jamais grâce à un individu. Il tient grâce à un collectif capable de se parler franchement. Capable de confronter les points de vue sans ego. Capable de partager la responsabilité et de dire non ensemble quand il le faut. Parce qu'un expert seul finit épuisé, bridé, ou utilisé comme fusible. Tandis qu'un collectif qui assume ? Ça, ça change la donne. Je ne dénigre pas l'expertise individuelle. Mais je ne crois plus au héros solitaire, c'est un mythe qui coûte cher en réalité. La vraie valeur ne vient pas d'un expert seul. Elle vient de personnes qui portent collectivement.

Dans une carrière, il y a des collègues. Et puis il y a ce type-là. J’ai croisé beaucoup d’ingés brillants. Mais Frédéric, c’était autre chose. C’est le gars qui voit le code comme Paul Atréides voit les futurs possibles : toutes les branches, tous les commits, tous les cas limites… en même temps. Le type qui met en prod… pendant que tout le monde a encore planifié un atelier de cadrage. Moi en 15 ans de vie pro, des profils comme lui, j’en ai croisé pas beaucoup. Ne le laissez pas juste défiler dans votre feed : il risque d’être déjà en prod ailleurs.

Il y a 15 ans, j'ai cherché une boîte qui n'existait pas. Aujourd'hui, je me demande ce qui se passerait si elle existait... Me lancer dans ce modèle économique ? L'idée m'aurait fait rire. Pendant des années, j'ai vu ce secteur de l'intérieur. Des devs traités comme des lignes Excel. Des seniors sur le papier, des juniors dans le code. Projets acceptés par opportunisme, pas par conviction. Je me suis juré : jamais ça. Jamais transformer un expert en variable d'ajustement. Jamais envoyer quelqu'un seul au front sans soutien. Jamais. J'ai vu un CTO que je respecte s'effondrer devant moi. Épuisé de micro-manager des profils qu'il ne connaissait pas. Fatigué de combler l'écart entre la promesse et la réalité. Dégouté de laquer 800€/jour pour quelqu'un qui découvre la stack. "Illiyas, il doit bien exister une alternative, non ?" Ce jour-là, j'ai arrêté de me demander pourquoi le système ne changeait pas. Et j'ai commencé à imaginer ce que serait un modèle qu'on aurait tous voulu rejoindre il y a 15 ans. Aujourd'hui, cette idée ne me lâche plus. Dire non quand un projet n'a pas de sens. Partager le risque avec les clients. Redistribuer la valeur à ceux qui la créent. Facturer l'impact réel, pas aux heures passées. L'idée qui a tout changé ? 👉 Arrêter de chercher la boîte idéale 👉 Et imaginer l'alternative qu'on aurait tous voulu voir exister Parfois, la seule solution, c'est de construire ce qui manque.