# Le test du successeur : un autre développeur pourrait-il reprendre ton app demain ?

Mik Bry · 2026-08-25 · lecture ~6 min · Launch Readiness · Documentation

![Une chaise vide devant un bureau, un ordinateur portable ouvert sur une fenêtre de discussion silencieuse, un carnet vierge posé sur le bureau.](/assets/2026-08-25-kb-project-continuity-hero.png)
Voici une question à te poser dès aujourd'hui, avant qu'il n'y ait le moindre problème : si tu embauchais un développeur demain, est-ce qu'il pourrait ouvrir ton projet et le reprendre directement — ou sa première phrase serait-elle « laisse-moi une semaine pour tout lire avant de pouvoir te chiffrer quoi que ce soit » ? Cet écart coûte du temps et de l'argent, que tu changes un jour de développeur ou non.
Dans cet article
1. [Qu'est-ce que c'est ?](#s1) 2. [Pourquoi un non-développeur devrait s'en soucier ?](#s2) 3. [À quoi ressemble une bonne pratique ?](#s3) 4. [Que peux-tu demander à ton agent IA sans risque ?](#s4)

01 — Qu'est-ce que c'est ?

Les équipes de développement ont un nom pour ce risque : le **facteur bus** — le nombre de personnes qui pourraient disparaître d'un projet avant qu'il ne soit vraiment en danger. Un projet avec un facteur bus unitaire dépend entièrement d'une seule personne, celle qui porte actuellement tout le contexte dans sa tête. Une étude de 2016, largement citée, portant sur 133 projets open source populaires sur GitHub, a trouvé que 46 % d'entre eux dépendaient essentiellement d'une seule personne. Il s'agissait de projets établis, avec un historique de commits remontant à plusieurs années. Une personne qui construit son projet seule, principalement avec l'IA, peut facilement se retrouver avec un facteur bus unitaire — sans que ce soit jamais un choix conscient.

Référence : Avelino, Passos, Hora & Valente (2016), « A Novel Approach for Estimating Truck Factors », ICPC — vérifié le 2026-08-25.

J'appelle ça le « test du successeur » : pourrais-tu confier ce projet à un autre développeur maintenant, et obtenir en retour un devis à prix fixe qui tienne debout — sans d'abord le payer une semaine rien que pour comprendre ce que fait ton app et comment elle est construite ? Ce qu'on lit habituellement sur le « facteur bus » ou la « reprise de projet » suppose presque toujours un prédécesseur humain que le nouveau développeur peut interroger. Ce n'est pas ta situation. Si ton app a été construite avec Cursor, Claude Code, Lovable, v0, Replit ou un outil similaire, une bonne partie du contexte qui explique pourquoi le code est comme ça — les compromis discutés, les raccourcis acceptés, les « on corrigera ça proprement plus tard » — ne s'est jamais retrouvée dans un commentaire ou un message de commit. Ce contexte peut n'exister que dans une conversation avec ton IA — hors du dépôt, invisible pour le prochain développeur. Retrouver pourquoi une décision a été prise dans une vieille conversation avec l'IA peut être plus difficile que de le demander directement à la personne qui l'a prise.

02 — Pourquoi un non-développeur devrait s'en soucier ?

Pas besoin d'anticiper une catastrophe pour s'en soucier. Le coût apparaît immédiatement, dès la première fois où tu as besoin d'aide extérieure, pour n'importe quelle raison — embaucher ton premier développeur, faire intervenir une agence, prendre un·e associé·e technique, ou simplement demander à un·e freelance de corriger un bug pendant que tu es occupé ailleurs. Sans documentation minimale, beaucoup de ces conversations commencent par une variante de : « il faut d'abord qu'on comprenne le code avant de pouvoir chiffrer le travail ». Ce temps de découverte peut ensuite se retrouver dans les devis que tu reçois. Vois ça comme la recette et le plat fini. Ton app qui fonctionne, c'est le plat — il a l'air bon et il a bon goût, et ça vaut vraiment quelque chose. Mais un nouveau cuisinier ne peut pas le reproduire, l'améliorer ou changer un ingrédient en toute sécurité sans la recette : ce qu'elle contient, pourquoi elle est construite ainsi, ce qui se passe si on change un ingrédient. La plupart des porteurs de projet imaginent une reprise comme la remise d'un classeur bien rangé — un README clair, un court « voici comment ça marche », une liste des décisions et de leurs raisons. Ce qui est réellement transmis, la plupart du temps, c'est le plat fini sans aucune recette : une app qui fonctionne et une fenêtre de discussion fermée.

03 — À quoi ressemble une bonne pratique ?

Pas besoin d'une documentation professionnelle pour réussir le test du successeur. Il te faut trois choses, chacune assez courte pour se lire d'une traite, et chacune assez simple pour que tu puisses — sans écrire une ligne de code — demander à ton propre outil d'IA de la rédiger directement à partir de ton projet existant : - **Un README.** Ce que fait l'app, à qui elle s'adresse, comment la lancer en local, et où se trouvent les éléments importants. - **Un résumé d'architecture en langage clair.** Quelques paragraphes, aucun schéma nécessaire : quelles sont les grandes parties (l'app, la base de données, le prestataire de paiement, le service d'e-mail, et les autres services auxquels elle se connecte), et comment elles s'articulent, grosso modo. - **Un journal de décisions en langage clair.** Pas un changelog de *ce qui* a changé — un court résumé de *pourquoi* les choix importants ont été pris, le genre de chose qui, jusque-là, ne se trouvait que dans ton historique de conversation. Pas besoin d'aller beaucoup plus loin à ce stade. Comme l'écrivait Tom Preston-Werner en 2010, en plaidant pour écrire le README avant le code : un logiciel sans documentation utile ne vaut presque rien pour quiconque ne le comprend pas déjà, et écrire ton intention est ce qui permet à quelqu'un d'autre d'y contribuer. C'était vrai avant même l'existence du développement assisté par IA, et ça reste vrai maintenant que le premier jet de ton code vient d'une conversation plutôt que d'un clavier.

Référence : Preston-Werner, « Readme Driven Development » (2010).

04 — Que peux-tu demander à ton agent IA sans risque ?

C'est une question de constat, pas une instruction de « va écrire la doc ». Tu diagnostiques l'écart avant de décider quoi en faire — la même discipline du « pas trouvé » que partout ailleurs dans cette série : un agent qui ne trouve pas de documentation doit dire qu'il n'en a trouvé aucune, pas supposer qu'il n'a pas besoin d'en écrire davantage.
À demander à ton agent IA — lecture seule
*« Un autre développeur pourrait-il reprendre ce projet à partir de la seule documentation ? Liste les trois lacunes les plus importantes. N'écris rien pour l'instant. »*
Lis la réponse attentivement. Si l'agent dit n'avoir trouvé aucune documentation, ce constat *est* ta première lacune — pas un signe que le test a échoué. Laisse reposer la liste un jour avant de décider quoi corriger, si tu décides de corriger quelque chose. Cette décision t'appartient ; le prompt ci-dessus est juste là pour que tu la prennes en connaissance de cause, plutôt que de tout découvrir pendant une vraie reprise. Cet article fait partie de la série Launch Readiness KB : un concept à la fois pour comprendre ce que le Trust Report vérifie avant de lancer ton app, d'embaucher ou de lever des fonds. Chaque article se termine par quelque chose que tu peux demander à ton agent sans modifier le code.