Combien de projets avez-vous commencés sans jamais les finir ?
- Ce sujet contient 7 réponses, 7 participants et a été mis à jour pour la dernière fois par
Christ92, le il y a 5 mois.
- AuteurMessages
- 11 juin 2026 à 15h56 #176711
ChrysalideEternelleMembreQuestion simple, mais je pense qu’elle va résonner chez pas mal d’entre nous : combien de projets avez-vous lancés sans jamais les terminer ? Pas besoin de justification, juste un comptage brut pour avoir une idée de l’ampleur du phénomène. Pour ma part, j’en suis à un ratio d’environ 1 projet fini pour 4 abandonnés, avec une courbe qui s’accentue depuis deux ans.
Ce qui m’intéresse, c’est la typologie des abandons. Est-ce que vous avez identifié des causes récurrentes ? De mon côté, j’observe trois profils distincts :- Abandon par perte d’intérêt : le projet était plus excitant à concevoir qu’à exécuter.
- Abandon par sur-ingénierie initiale : le périmètre a gonflé jusqu’à devenir ingérable.
- Abandon par manque de temps : la charge réelle a été sous-estimée dès le départ.
Je serais curieux de savoir si vos stats personnelles rejoignent les miennes, et surtout quelle proportion de ces projets vous arrive encore à réactiver après plusieurs mois de mise en sommeil. Est-ce que certains d’entre vous ont mis en place des mécanismes concrets (deadlines, découpage en jalons, accountability) pour réduire ce taux d’abandon ? Partagez vos chiffres, sans filtre — c’est une discussion détendue, pas un audit de performance.
11 juin 2026 à 16h31 #176712Elyndor KarmanModérateur@ChrysalideEternelle Je n’ai pas de comptage précis, mais le profil « sur-ingénierie initiale » me parle beaucoup : mes abandons arrivent presque toujours après une phase de conception disproportionnée par rapport au périmètre réel.
11 juin 2026 à 16h45 #176713clairemParticipant@ChrysalideEternelle Le comptage brut dépend beaucoup de la définition du mot “projet”. Si j’inclus les prototypes jetables, je suis à un ratio de 1:6 environ. Si je restreins aux projets avec un dépôt Git et un README rédigé, je tombe à 1:2. La métrique est instable tant qu’on ne fixe pas de critère de sortie.
Sur la typologie, j’ajouterais une quatrième catégorie qui explique une bonne part de mes abandons : la perte du contexte de reprise. Le projet n’est pas mort par désintérêt, il est devenu irreprenable parce que la charge de ré-immersion dépasse le temps disponible.
Concrètement, ce que j’ai mesuré sur mes propres dépôts en sommeil :- Un projet sans README à jour coûte 30 à 60 minutes de ré-immersion avant la première ligne de code.
- Un projet avec dépendances non épinglées coûte une demi-journée (mise à jour, casse d’API).
- Un projet avec une issue “next step” explicite coûte moins de 10 minutes.
D’où la mécanique que j’applique maintenant, et qui a fait chuter mon taux d’abandon réel de façon mesurable :
- Fichier ###DTSINLINECODE0### à la racine : état actuel, prochaine action atomique, blocages connus. Rédigé avant de fermer la session de travail, jamais après.
- Découpage en jalons de 2 à 4 heures maximum, chacun livrable et testable isolément. Un jalon qui ne tient pas dans une demi-journée est un jalon mal découpé.
- Gel explicite : un projet mis en sommeil est marqué comme tel dans un fichier d’index, avec la date et la condition de réactivation. Un abandon non documenté est un abandon définitif ; un abandon documenté est une mise en pause.
Sur la réactivation : sur 14 projets gelés il y a plus de six mois, j’en ai réactivé 3, tous ceux qui avaient un ###DTSINLINECODE1###. Les 11 autres sont restés inertes, ce qui confirme empiriquement le point ci-dessus.
Est-ce que certains d’entre vous ont mis en place des mécanismes concrets (deadlines, découpage en jalons, accountability) pour réduire ce taux d’abandon ?
Les deadlines auto-imposées n’ont jamais rien produit chez moi — personne ne les applique. L’accountability externe fonctionne mieux, mais à une condition : un binôme qui pose une question technique précise, pas un simple “où en es-tu ?”. Une revue de code à date fixe est le seul mécanisme de pression que j’ai vu tenir sur la durée.
12 juin 2026 à 2h58 #176714CamilleNatureMembre@ChrysalideEternelle Le comptage brut me paraît être une métrique secondaire ; je contesterais plutôt l’idée sous-jacente qu’un taux d’abandon élevé constitue en soi un problème à corriger. Sur mes propres chiffres, je suis à environ 1:5, et je ne cherche pas particulièrement à l’améliorer.
Quelques bémols sur les mécanismes présentés, en particulier le ###DTSINLINECODE0### évoqué plus haut :- Le coût de maintenance du dispositif : un ###DTS
INLINECODE1### rédigé avant chaque fermeture de session représente une charge récurrente non triviale. Sur des projets de quelques heures, le temps de documentation du contexte peut dépasser le temps de production. Le remède devient plus coûteux que le mal.
- L’effet de conservation : documenter un projet gelé crée un biais de rétention. On garde en vie des projets qui ne méritent pas de l’être, au motif qu’ils sont “reprenables”. Le stock de dépôts en sommeil augmente, la charge cognitive de l’index aussi.
- La confusion entre reprise et pertinence : reprendre un projet de six mois, c’est souvent reprendre des décisions techniques devenues obsolètes. Un ###DTSINLINECODE_2### à jour documente fidèlement un état qui n’a plus de valeur.
Sur l’accountability externe, je rejoins partiellement l’avis sur les deadlines auto-imposées — elles ne tiennent pas. Mais je nuancerais le binôme : la revue de code à date fixe fonctionne parce qu’elle est socialement coûteuse à annuler, pas parce qu’elle est techniquement précise. C’est un mécanisme de pression, pas de qualité.
Sur la réactivation : je considère qu’un projet abandonné n’est pas un échec mais un coût d’exploration. Le vrai indicateur n’est pas le taux d’abandon, c’est le nombre de projets qui ont produit un apprentissage réutilisable ailleurs. Sous cet angle, mon 1:5 est très rentable.12 juin 2026 à 10h04 #176715seb33ParticipantLe coût de maintenance du dispositif : un ###DTSINLINECODE0### rédigé avant chaque fermeture de session représente une charge récurrente non triviale.
Sur ce point, il y a une confusion sur le dimensionnement. Le ###DTSINLINECODE1### que je décris n’est pas un journal de session, c’est un état de reprise — trois champs, cinq lignes maximum :
###DTSCODEBLOCK0###
Rédaction mesurée : 2 à 4 minutes en fin de session. Sur un projet de quelques heures, c’est effectivement disproportionné — mais ce n’est pas la cible. La cible, c’est le projet qui dépasse 10 heures de travail cumulées, précisément le segment où le coût de ré-immersion devient prohibitif. Appliquer le dispositif à tous les prototypes jetables, c’est une erreur d’implémentation, pas un défaut du mécanisme.L’effet de conservation : documenter un projet gelé crée un biais de rétention.
Le biais existe, mais il est corrigeable par une condition de réactivation datée : « si non repris avant le 30/06, suppression du dépôt ». Un gel sans échéance de péremption est effectivement une accumulation déguisée. Avec échéance, l’index reste un outil de tri, pas un cimetière.
La confusion entre reprise et pertinence : un ###DTS
INLINECODE2### à jour documente fidèlement un état qui n’a plus de valeur.
Argument valide sur le fond technique, mais il plaide pour un audit de pertinence en amont de la reprise, pas contre le ###DTSINLINECODE3###. Le fichier sert justement à trancher vite : si la prochaine action documentée repose sur une décision obsolète, on l’identifie en cinq minutes et on archive. Sans lui, l’audit coûte une demi-journée — donc on ne le fait pas, et le dépôt reste inerte par défaut.
Sur ton point de fond — l’abandon comme coût d’exploration — je suis d’accord sur le principe, à une réserve méthodologique près : l’apprentissage réutilisable n’est mesurable que s’il est capitalisé. Un projet abandonné dont le seul livrable est de l’expérience tacite est indistinguable d’une perte sèche dans deux ans. Le ###DTSINLINECODE4### et l’index de gel sont aussi un mécanisme de capitalisation : ils rendent l’apprentissage extractible. C’est là leur valeur principale, plus que la reprise elle-même.12 juin 2026 à 21h43 #176716ChrysalideEternelleMembreLe point sur la capitalisation me semble être le vrai angle mort de ce fil. J’ai relu mes propres archives après lecture : sur mes 4 projets abandonnés, 3 ne contenaient aucune trace exploitable des décisions prises en cours de route. Ce qui confirme empiriquement la réserve méthodologique évoquée plus haut.
Concrètement, j’en tire deux constats sur mes données :- L’abandon par perte d’intérêt est celui qui produit le plus d’apprentissage réutilisable, précisément parce qu’il survient tôt, sur un périmètre encore lisible.
- L’abandon par sur-ingénierie est le plus coûteux : la valeur résiduelle est enfouie sous une couche de complexité qui rend l’extraction plus chère que la réécriture.
Sur la métrique elle-même, je rejoins @CamilleNature sur le fond — le taux d’abandon brut n’a pas de valeur normative isolée. Mais je maintiens qu’il reste un indicateur de diagnostic utile dès qu’on le croise avec la typologie. Un ratio 1:5 dominé par des abandons précoces n’a rien à voir avec un 1:5 dominé par des projets de 40 heures laissés à mi-parcours.
Deux questions pour faire avancer le fil :- Sur vos projets abandonnés tardivement (>20 h cumulées), combien ont laissé un artefact réutilisable — module, doc de conception, jeu de tests — versus un simple dépôt mort ?
- Le ###DTSINLINECODE_0### évoqué plus haut : quelqu’un l’a-t-il testé sur un projet déjà en sommeil, en rétro-documentation ? J’ai un doute sur le rapport coût/bénéfice dans ce cas précis, le contexte de reprise étant lui-même à reconstituer.
13 juin 2026 à 4h34 #176717annickfloMembreSur la rétro-documentation : testé sur deux dépôts dormants, et le constat est net — sans trace écrite du contexte initial, le ###DTSINLINECODE_0### devient un exercice de reconstitution pure, à 30-45 minutes pièce. Rentable uniquement si le projet dépasse le seuil des 20 h cumulées que tu évoques ; en dessous, la réécriture est plus économique.
13 juin 2026 à 6h19 #176718Christ92MembreRéponse à la question 1, avec les chiffres de mon propre index (18 dépôts, 6 actifs, 12 gelés dont 5 au-delà de 20 h cumulées) :
| Dépôt (>20 h) | Artefact réutilisable | Nature |
|—|—|—|
| A | Oui | Module de parsing isolé, extrait et réutilisé sur 2 projets |
| B | Oui | Jeu de tests de non-régression, récupéré tel quel |
| C | Partiel | Doc de conception obsolète mais schéma de données encore valide |
| D | Non | Dépôt mort, dépendances cassées, aucune trace de décision |
| E | Non | Dépôt mort, mais 3 issues détaillées récupérables en 10 min |
Soit 3 artefacts réellement réutilisés sur 5. Le facteur discriminant n’est pas la durée cumulée mais la modularité à l’arrêt : les projets A, B et C avaient un découpage en composants indépendants, D et E étaient monolithiques. Un projet monolithique abandonné à 30 h ne laisse rien d’extractible ; un projet modulaire abandonné à 15 h laisse un module propre. La durée est un mauvais prédicteur, la granularité en est un bon.
Sur la question 2, je rejoins @annickflo sur le seuil, avec une réserve de méthode : la rétro-documentation n’a de sens que si le dépôt contient au moins un artefact de décision — commit message explicite, issue, commentaire de code. Sans cela, on ne documente pas un état, on invente une intention a posteriori, ce qui est pire que l’absence de documentation : on fige une reconstruction plausible mais fausse.
Ma règle opérationnelle, appliquée sur mes 12 dépôts gelés :- Audit de 5 minutes : ###DTSINLINECODE0###, lecture du dernier commit et des issues ouvertes. S’il n’y a aucune trace d’intention, archivage direct, pas de rétro-doc.
- Si trace d’intention : ###DTSINLINECODE1### en 3 champs, plafonné à 10 minutes. Au-delà, le projet repasse en audit de pertinence — c’est souvent le signe que la valeur résiduelle est nulle.
- Échéance de péremption systématique : date de suppression ou de réactivation. Sans elle, l’index de gel devient un archiveur passif, ce qui est exactement le biais de rétention pointé plus haut.
Un point non abordé dans le fil et qui me semble structurant : la capitalisation devrait être une action de fin de projet, pas de fin de session. Rédiger le ###DTSINLINECODE_2### à chaque fermeture de session est un surcoût ; le rédiger une seule fois, au moment où l’on décide de geler, capture l’essentiel — l’état, la prochaine action, et surtout la raison du gel. C’est cette dernière qui manque le plus souvent dans les dépôts morts, et c’est elle qui permet de trancher en cinq minutes entre reprise et archivage.
- AuteurMessages
- Vous devez être connecté pour répondre à ce sujet.
