Sillon
Sillon
Document réel — tel quel

Regarde ce document. Chaque ligne porte sa fiche et sa date.

Un document de travail réel — la checklist de lancement de ma prochaine app, tirée de mes fiches — rendu tel quel : rien n'a été maquillé, ni les dates, ni les trous.

5 sections·22 citations·5 hypothèses déclarées

Sections 1 à 5, plus le récapitulatif des hypothèses qui les referme. Les compteurs sont ceux du document, pas des arrondis.

Deux encres. Pas de troisième.

Chaque affirmation qui engage est d'une de ces deux encres. Une phrase ni l'une ni l'autre est un défaut — et il se voit.

Sourcée
[retour-d-experience-sur-14-applications-mobiles-et-saas-deve §reading · 2026-08-01]

La fiche, la section, la date. Trois choses qu'une machine peut retrouver — ou pas. Le slug complet est dans la page ; l'écran l'abrège, la vérification non.

Hypothèse
HYPOTHÈSE — à confirmer

Ce que les fiches ne tranchent pas est écrit comme tel, filet hachuré à l'appui. Ni vert, ni rouge : déclarer qu'on ne sait pas, c'est le contrat qui tient, pas une alerte.

Trois passages du document. Tels quels.

Une section entière, le récapitulatif des hypothèses, et une règle isolée — copiés du document sans retouche : ni l'ordre, ni les mots, ni les crochets.

Extrait · section 1 Avant d'écrire une ligne de code
  • Identifier mon « marteau » d'abord — le canal que je sais réellement manier (contenu viral organique, cold outreach, ou publicité payante) se choisit AVANT de construire, pas après [retour-d-experience-sur-14-applications-mobiles-et-saas-deve §reading · 2026-08-01].
  • Un business model viable dès le départ — le cas du produit aimé de ses utilisateurs mais sans modèle économique est documenté : succès d'usage, impasse financière [retour-d-experience-sur-14-applications-mobiles-et-saas-deve §reading · 2026-08-01].
  • Valider l'adéquation produit / public / canal avant le développement [retour-d-experience-sur-14-applications-mobiles-et-saas-deve §checks · 2026-08-01].
  • Être mon propre utilisateur — les projets les plus durables sont ceux où le fondateur est un utilisateur actif ; l'abandon faute d'usage personnel est documenté [retour-d-experience-sur-14-applications-mobiles-et-saas-deve §reading · 2026-08-01].
  • Copier pour valider, prévoir l'innovation pour durer — la copie stratégique valide un marché, mais le plateau qui suit exige un axe de différenciation préparé d'avance [retour-d-experience-sur-14-applications-mobiles-et-saas-deve §x1 · 2026-08-01].
  • HYPOTHÈSE — à confirmer : mon marteau. Les fiches donnent le cadre de décision, pas mon cas — il se confirmera par mes propres essais de contenu, pas par une intuition.

Cinq règles qui engagent, cinq citations. La sixième ligne n'en a pas — alors elle le dit.

Les citations qui pointent vers la section montrée plus bas sont cliquables : elles t'emmènent sur la ligne exacte. Les autres désignent des sections que cette page n'affiche pas.

Extrait · section 6 HYPOTHÈSE — à confirmer Récapitulatif des hypothèses à confirmer
  • Mon marteau marketing (§1) — par essais, pas par intuition.
  • Mon rythme de publication tenable (§2).
  • Le pricing de ma prochaine app — aucune des deux fiches ne porte de grille applicable à mon cas : HYPOTHÈSE entière, à construire.
  • iOS-first pour moi ? — la fiche justifie iOS par le ROI et la complexité moindre [retour-d-experience-sur-la-creation-d-une-application-mobile §anomalies · 2026-08-01], mon cas reste à valider.
  • Mon budget quotidien réel (§5).

Le document aurait pu inventer un pricing, un rythme, un canal. Il déclare qu'il ne sait pas — cinq fois.

Extrait · section 4 Après : croissance et plateaux
  • Surveiller les plateaux de revenus — le plateau à 2 000 $/mois sans axe d'innovation est documenté comme limite connue de la copie stratégique [retour-d-experience-sur-14-applications-mobiles-et-saas-deve §anomalies · 2026-08-01] — cité ici pour ne pas le « redécouvrir » le jour où il arrivera.

limite connue — citée, pas redécouverte

La fiche connaît déjà ce plateau. Le document le cite — il ne le « découvre » pas une deuxième fois.

Non montrées ici : les sections 2, 3 et 5 — pendant la construction, le lancement, le cadre de vie — et le reste de la section 4. Même forme, mêmes encres.

L'audit passe après moi. Et il compte.

Avant que ce document ne sorte, un outil de lecture relit ses crochets un par un, contre les fiches réelles.

checklist.md
$ verify_citations(checklist.md)

22 citations · 22 résolvent · 0 malformée

# audité le 5 août 2026 — sur les fiches de ce jour-là
  1. Déterministe. Pour chaque [fiche §section · date], il contrôle que la fiche existe, que la section existe, et qu'une ligne de cette section a bien été écrite à cette date ; une citation fabriquée ne passe pas.
  2. Il ne juge pas la phrase. Il garantit que la référence est réelle ; que la phrase la porte bien, c'est ta relecture qui le dit.
  3. La chaîne s'arrête à la fiche. L'audio d'origine est détruit à la validation — on te promet la fiche et sa date, jamais « la preuve par l'enregistrement ».
Ce que fait le vérificateur, en détail

Chaque citation reçoit exactement un verdict. Tout ce qui n'est pas ok est un défaut à corriger avant de rendre le document — jamais quelque chose qu'on laisse passer.

  • okLa citation tient. La fiche existe, la section existe, et une ligne de cette section porte cette date.
  • unknown_subjectFiche inconnue. Le slug cité ne correspond à aucune de tes fiches — citation fabriquée, ou fiche renommée.
  • unknown_sectionSection inconnue. La fiche existe, mais pas la section citée.
  • no_line_for_dateAucune ligne à cette date. La fiche et la section existent, mais rien n'y a été écrit ce jour-là. Le cas le plus fréquent est une ligne reformulée depuis : elle a été re-datée, donc l'ancienne date ne résout plus.

Le compteur « malformée » est à part : il relève les crochets qui ont essayé d'être une citation sans en respecter la grammaire. C'est un plafond à regarder à l'œil, pas une preuve — de la prose ordinaire entre crochets le fait monter.

Où la citation atterrit.

Une citation ne pointe pas vers un document produit par une IA : elle pointe vers une ligne de fiche — une ligne que j'ai validée, à la date où je l'ai validée.

La section §reading de la fiche, telle qu'elle se lit — réécrite pour cette page sans les noms d'apps tierces.

Retour d'expérience sur 14 applications mobiles et SaaS développées en side-project
Référence
§reading · Comment le lire
Le « marteau » — le canal qu'on sait réellement manier (contenu organique, cold outreach, publicité payante) se choisit avant de construire. 2026-08-01
Le business model — un produit aimé de ses utilisateurs sans modèle économique : succès d'usage, impasse financière. 2026-08-01
Copier puis innover — la copie stratégique valide un marché ; sans axe de différenciation préparé, elle plafonne. 2026-08-01
Le fondateur-utilisateur — les projets qui durent sont ceux où le fondateur reste un utilisateur actif. 2026-08-01
Le timing — un échec sur un marché non éduqué ne condamne pas l'idée : le marché a mûri ensuite, porté par d'autres. 2026-08-01
Mêmes règles, mêmes dates, mêmes ancres — les mots exacts vivent dans la fiche ; ici, elle est resserrée et les noms tiers retirés. C'est ici que la citation atterrit : une ligne, sa date.

Ce qu'on ne te promet pas.

Pas l'infaillibilité

Le contrat rend le défaut visible, pas impossible. Une phrase peut être mal tournée : elle se repère parce qu'il manque son encre.

La référence, pas l'idée

Le vérificateur garantit que la ligne citée existe à cette date. Que la phrase dise vrai de cette ligne, c'est ton jugement.

Une date, pas une origine

La date est celle de la dernière formulation de la ligne. Reformuler re-date : c'est la même mécanique qui te l'apprend.

Un outil qui te promet l'infaillibilité te demande de le croire. Celui-ci te montre où vérifier.

Le livrable, c'est l'étage du haut. Ça commence par des fiches : l'app est la porte.

Le document de cette page a été rédigé depuis mes propres fiches, puis audité par verify_citations — l'outil de lecture que ton IA peut appeler.