Aller au contenu principal

Articles · Méthodologie

Méthodologie : cadrer, tester et livrer un projet web

Articles sur la méthode : cahier des charges, MVP, stratégie de tests, audit de sécurité et conduite de projet.

À lire en premier

8 articles

Technique · Méthodologie · IA · · 13 min

Un plugin Claude Code pour les conventions de toute l'équipe

Guider un assistant de code comme Claude Code se fait au contexte : conventions de nommage, règles de style, recettes pour ouvrir une MR ou répondre à une review. Le réflexe est d'écrire tout cela dans un CLAUDE.md par projet — et de le dupliquer, désynchronisé, sur des dizaines de dépôts. Ce retour d'expérience, tiré d'un éditeur SaaS aux nombreux repos frères, décrit une autre voie : packager le workflow de l'équipe dans un plugin Claude Code interne, versionné et distribué comme une dépendance via un marketplace privé. Commandes git/Jira/GitLab, règles transverses (style, sécurité, dimensions de review), agents, hooks de vérification d'environnement — aucun secret dans le plugin, seulement des vérifications : tout vit à un seul endroit et tous les repos en héritent. L'article revient au passage sur un malentendu fréquent — croire qu'une doc humaine (README, wiki) suffit à l'assistant, alors que doc humaine et doc pour l'assistant servent deux publics et appellent deux formats différents. Il détaille ce qu'on y met, pourquoi la source unique de vérité et le cycle de vie découplé changent la donne pour l'onboarding et la cohérence des reviews, et les limites — coût de maintenance, risque de fourre-tout, adoption d'équipe — pour ne pas sur-outiller.

Décideurs · Prestataires · Méthodologie · · 12 min

Plus de 10 ans de prestation freelance pour Orange

Août 2015, premier commit. Avril 2026, toujours en mission. Plus de 10 ans de prestation freelance continue pour la direction technique d'Orange : 5 projets, des migrations Symfony 2 à 6.4, un passage sur OpenShift, une image Docker maison et une librairie PHP partagée. Cet article est un retour d'expérience sur ce qui fait durer une relation freelance/grand compte sur la durée : confiance mutuelle, autonomie, résultats constants et zéro raccourci technique.

Technique · Méthodologie · Développement · · 12 min

TDD, BDD ou tests a posteriori : lequel choisir

TDD (Test-Driven Development), BDD (Behavior-Driven Development) et tests a posteriori répondent à des objectifs différents. Cet article les compare sans dogmatisme : quand le TDD apporte un vrai gain (logique métier complexe, algorithmes), quand le BDD clarifie les spécifications (projets multi-parties prenantes), et quand les tests a posteriori sont le choix pragmatique (legacy, prototypage, dette technique). Il propose une combinaison optimale par couche applicative et un plan d'adoption progressif.

Technique · Méthodologie · Développement · · 14 min

Tests automatisés sur un projet legacy

Ajouter des tests sur un projet legacy semble impossible : code couplé, pas d'injection de dépendances, aucune couverture existante. Pourtant, c'est précisément là que les tests ont le plus de valeur. Cet article propose une stratégie pragmatique : commencer par les tests de caractérisation (documenter le comportement actuel), identifier les zones à risque, introduire des coutures (seams) pour rendre le code testable sans le réécrire, et augmenter la couverture progressivement en ciblant les modules critiques.

Décideurs · Sécurité · Méthodologie · · 10 min

Audit de sécurité applicatif : quand et comment

Un audit de sécurité applicatif n'est pas un luxe réservé aux grands comptes. Cet article détaille quand le réaliser (avant production, après changement majeur, périodiquement, après incident), les types d'audit (revue de code, pentest boîte noire/grise/blanche, audit de configuration), le déroulement en 5 étapes (cadrage, reconnaissance, analyse, rapport, restitution), ce que doit contenir un bon rapport et le plan de remédiation avec ses délais de correction par criticité.

Technique · Architecture · Méthodologie · · 14 min

Migrer une application legacy sans tout casser

Les refontes « big bang » échouent dans la majorité des cas : budget dépassé, périmètre qui dérive, legacy maintenu en parallèle bien plus longtemps que prévu. Le strangler fig pattern propose une alternative éprouvée : construire le nouveau système autour de l'ancien, module par module, en routant progressivement le trafic. Cet article détaille les cinq étapes concrètes (cartographie, couche de routage, migration par tranches, cohabitation, décommissionnement), la matrice de priorisation des modules, les pièges courants (big bang déguisé, oubli du décommissionnement) et les indicateurs de succès à suivre.

Décideurs · Stratégie · Méthodologie · · 14 min

MVP ou produit complet : comment cadrer le périmètre

MVP ou produit complet n'est pas un choix binaire, c'est une décision de cadrage. Cet article analyse les cinq critères concrets qui orientent vers l'une ou l'autre approche (nature du projet, maturité du besoin, contraintes réglementaires, budget, utilisateurs cibles), propose une méthode de priorisation fonctionnelle (MoSCoW, distinction core/support/confort), détaille les erreurs classiques du sur-cadrage (spécifier trop tôt, reporter le lancement, construire pour des hypothèses) et du sous-cadrage (pas de critères de succès, pas de trajectoire d'évolution), et illustre avec trois scénarios concrets : startup SaaS, PME industrielle et e-commerce B2B.

Décideurs · Stratégie · Méthodologie · · 12 min

Comment rédiger un cahier des charges web efficace

Le cahier des charges est le document le plus sous-estimé d'un projet web. Beaucoup s'en passent ou le bâclent, puis découvrent les conséquences à mi-parcours : périmètre flou, budget dépassé, livrable qui ne correspond pas au besoin. Cet article propose un guide actionnable pour rédiger un cahier des charges efficace : les sections indispensables, les erreurs les plus fréquentes, les critères qui distinguent un bon document d'un mauvais, et les cas où se faire accompagner fait la différence.

À propos de cette sélection

La plupart des projets qui dérapent le font avant la première ligne de code, par un besoin mal cadré, ou après, faute de tests et de rigueur de livraison.

Ces articles décrivent la méthode que j'applique, du cahier des charges au MVP et à la stratégie de tests.

Contact

Un sujet vous intéresse ?

Vous avez une question technique ou souhaitez approfondir un sujet abordé dans ces articles ? N'hésitez pas à me contacter pour en discuter.

Me contacter arrow_forward