Cette page explique comment je construis les articles de L’Ingénieur Pragmatique — pas pour me justifier, mais parce qu’un lecteur qui sait d’où vient un conseil peut mieux juger s’il s’applique à sa propre situation.
D’où viennent mes anecdotes
Chaque article s’appuie sur au moins une situation vécue, anonymisée, tirée de mes quinze ans chez IBM France ou de mes treize années de conseil auprès de plus de quatre-vingts PME entre Rennes et Dijon. Je ne reconstitue jamais un cas de mémoire pure : dates, contexte technique et enjeu métier doivent rester cohérents avec l’époque évoquée.
Comment j’utilise les cadres théoriques
Je mentionne parfois des frameworks de stratégie — Porter, McKinsey, STEEPL, la théorie de l’agence. Je ne les cite jamais pour le principe : un cadre théorique n’apparaît dans un article que s’il éclaire un cas réel ou répond à une question qu’un entrepreneur m’a posée un jour.
Ce que je refuse d’écrire
Pas de superlatifs marketing — « révolutionnaire », « incontournable », « game-changer » n’apparaîtront jamais ici. Je privilégie « efficace », « pragmatique », « robuste ». Je ne recommande jamais un produit sans avoir d’abord expliqué le contexte et les alternatives : pourquoi celui-ci plutôt qu’un autre, pour votre situation précise.
Pour qui j’écris
Tous mes articles s’adressent aux PME et aux petites structures — jamais aux grandes entreprises, jamais aux startups en hypercroissance. Si un conseil ne s’applique qu’à une organisation de deux cents salariés avec un budget IT à sept chiffres, il n’a pas sa place ici.
Une mise en garde par article
Trente ans d’infrastructure m’ont appris qu’une solution technique séduisante cache souvent un piège que seul le recul révèle. Chaque article contient donc au minimum une mise en garde — un « attention à » — sur les coûts cachés, les migrations mal préparées ou les outils inadaptés.
Pour en savoir plus sur qui je suis, retour à la page à propos.