Doc Driven Programming

Introduction

On commence à coder, et la doc viendra “plus tard”. Résultat : elle ne vient jamais. On se lance dans le code sur la base de discussions orales, d’e-mails épars ou d’un ticket vaguement rédigé. Résultat : des malentendus, des choix techniques mal alignés avec les besoins, et un code difficile à maintenir.

Le Doc Driven Programming (DDP) propose une approche différente : commencer par écrire. Avant toute ligne de code, il s'agit de poser noir sur blanc ce que le logiciel doit faire, pourquoi il doit le faire, et comment on envisage de le faire. Cette documentation devient la référence unique à partir de laquelle le code est construit, étape par étape.

Ce n’est pas une méthode miracle, mais une discipline. Une manière de structurer le développement autour de l’intention, plutôt que de l’implémentation. Cet article présente les principes du DDP, ses bénéfices, ses limites, et les outils qui peuvent l'accompagner.

Pourquoi repenser une manière de développer ?

Le cycle de développement commence par un besoin plus ou moins bien exprimé, souvent flou, rarement formalisé. Le développeur reçoit une tâche, parfois rédigée à la hâte, qu’il doit interpréter, compléter, voire deviner. L'échange avec le métier est informel. La mémoire collective repose sur des conversations orales, des messages instantanés, ou pire : le souvenir d’un collègue qui n’est plus là.

Cette approche présente plusieurs risques :

• Perte de sens : le développeur sait quoi faire, mais pas pourquoi. Il exécute une tâche sans avoir la vision d’ensemble.
• Documentation absente ou rédigée après coup : souvent bâclée, incomplète, ou incohérente avec le code livré.
• Maintenance difficile : quelques mois plus tard, personne ne se souvient des décisions prises, ni des raisons techniques derrière certaines implémentations.
• Multiplication des erreurs d’interprétation : entre le besoin initial, la mise en œuvre, les tests et la validation, chaque étape ajoute son lot d’incertitudes.

Résultat : le code fonctionne peut-être, mais il ne raconte pas d’histoire. Il ne s’appuie sur aucune base écrite solide. Il devient difficile à transmettre, à corriger, à faire évoluer.

Le Doc Driven Programming ne prétend pas résoudre tous ces problèmes, mais il pose une base simple : documentons d’abord. Avant d’écrire une fonction, posons-nous les bonnes questions, écrivons les réponses, et construisons sur ces fondations.

Qu’est-ce que le Doc Driven Programming (DDP) ?

Le Doc Driven Programming est une approche de développement qui repose sur un principe fondamental : ne code pas ce qui n’est pas documenté.

Concrètement, cela signifie que tout développement logiciel commence par une phase de rédaction, où l’on décrit en détail le besoin fonctionnel, le comportement attendu, et les choix techniques envisagés. Ce document, central, sert ensuite de base à toute l’implémentation.

1. Une documentation fonctionnelle claire

Chaque fonctionnalité doit être décrite du point de vue de l’utilisateur ou du métier. Ce n’est pas une spécification formelle, mais un texte compréhensible qui répond à des questions simples :

• Que doit faire le logiciel ?
• Pourquoi en a-t-on besoin ?
• Quels sont les cas d’usage concrets ?

2. Une documentation technique cohérente

Avant même d’écrire le code, le développeur peut proposer ou expliciter :

• Les choix d’architecture (base de données, API, formats d’échange…)
• Les règles métier importantes
• Les contraintes techniques (sécurité, performance, compatibilité…)

3. Une traçabilité unifiée

Le document initial devient la source unique de vérité. Il centralise le besoin, les échanges, les décisions et le suivi de l’implémentation. On peut y rattacher :

• Le nom du développeur en charge
• Les dates clés
• Les liens vers les commits ou les tickets

Les avantages du Doc Driven Programming

Adopter le DDP, ce n’est pas ajouter une étape superflue, c’est replacer l’écriture au cœur du développement. Voici les bénéfices concrets que cette approche peut apporter :

1. Une meilleure compréhension des besoins

En obligeant à rédiger le besoin noir sur blanc, on évite les malentendus. Le développeur ne se contente plus d’exécuter une consigne floue, il comprend le pourquoi de la tâche, ce qui limite les erreurs d’interprétation.

2. Moins d’allers-retours avec les parties prenantes

Un besoin bien documenté dès le départ permet de valider plus rapidement ce qu’il faut faire. Moins de corrections, moins d’oubli, moins d’aller-retours liés à des oublis de contexte.

3. Un socle de référence durable

La documentation devient un point d’ancrage. Elle permet de revenir, même des mois plus tard, à l’origine d’un choix ou d’une fonctionnalité. On ne dépend plus de la mémoire d’un collègue ou d’un historique de messages introuvables.

4. Un gain de temps à moyen et long terme

Oui, rédiger demande un effort initial. Mais cet effort évite des corrections, des régressions, des incompréhensions, voire des refontes inutiles. Une documentation solide permet de développer avec confiance.

5. Un onboarding facilité

Un nouveau développeur qui arrive sur le projet peut lire la documentation et comprendre rapidement ce qui a été fait, pourquoi, et comment. Le DDP produit naturellement un historique exploitable.

6. Une séparation des rôles plus nette

Le chef de projet ou le référent métier rédige la partie fonctionnelle. Le développeur complète avec les choix techniques. Chacun se concentre sur son domaine d’expertise. Moins de zones grises, plus de clarté.

Limites et objections du Doc Driven Programming

1. “On n’a pas le temps pour ça.”

La rédaction demande un effort initial. Dans des contextes agiles mal appliqués ou des projets sous pression, la tentation est grande de “commencer direct”. Pourtant, ce temps de documentation est rarement du temps perdu : il évite des retours coûteux. Mais il faut l’assumer dans la planification.

2. “Les besoins évoluent trop vite.”

C’est vrai dans les environnements très mouvants. Mais ce n’est pas une excuse pour coder sans cadre. Le DDP n’interdit pas l’évolution : il impose simplement de reformuler clairement chaque étape. Et si ça change souvent, c’est d’autant plus utile d’avoir une trace des versions.

3. “Les développeurs ne sont pas rédacteurs.”

C’est justement pourquoi la documentation est partagée. Le fonctionnel peut être rédigé par le métier, le technique par le développeur. Ce n’est pas une prose littéraire qu’on attend, mais une clarté minimale sur ce qui est fait et pourquoi.

4. “On a déjà des tickets dans Jira / GitHub / Notion…”

Oui, mais souvent ces outils se limitent à un titre et une check-list. Le DDP implique une documentation qui précède le ticket et l’alimente. Ce n’est pas incompatible, c’est complémentaire. On peut intégrer le DDP dans ces outils avec un minimum de rigueur.

5. “Ça rigidifie le processus.”

Un peu, oui. Mais c’est aussi ce qui structure les échanges. On ne parle pas ici d’un processus bureaucratique, mais d’un canevas clair qui évite les “on pensait que…”. Le DDP favorise une forme d’agilité écrite, pas une paralysie.

Conclusion

Le Doc Driven Programming, ce n’est pas une méthode figée, encore moins une injonction de plus dans un monde du développement déjà saturé de dogmes. C’est une invitation à remettre l’écrit au centre de la conception logicielle.

Dans un contexte où les projets évoluent, les équipes changent, les intentions se perdent, le DDP propose une posture simple : le code ne devrait jamais précéder l’intention. Documenter d’abord, ce n’est pas perdre du temps, c’est en gagner pour plus tard.

En séparant clairement les rôles — le besoin exprimé d’un côté, la réponse technique de l’autre — on redonne sa juste place à la collaboration, à la transmission, à la mémoire du projet. Le développeur n’est plus un déchiffreur d’ombres passées, mais un exécutant éclairé d’une intention bien formulée.