Je construis mon app avec mon app : 18 mois de dogfooding solo

> Contexte: je développe DockSky seul, à 60 ans, autodidacte depuis 40 ans. L'app sert à garder le fil de mes projets et à brancher mon IA dessus. Et je m'en sers pour construire l'app elle-même. Ca fait 18 mois que ça tourne tous les jours.

Le dogfooding classique ne me suffisait pas

Quand une startup dit « on dogfoode notre produit », en général ça veut dire: l'équipe utilise son propre CRM, ou sa propre todo list, pour trouver des bugs.

Moi c'est différent.

Je ne teste pas une feature isolée. Je vis dans un système où mon cerveau, mon app et mon IA partagent la même mémoire. Si le système tient la route, c'est que le produit tient la route. Si ça casse, je le sens immédiatement parce que c'est mon quotidien qui se dégrade.

Ce n'est plus « je mange ma soupe ». C'est « ma soupe est le réseau nerveux de tout ce que je fais ».

Je ne prétends pas avoir inventé le dogfooding. J'ai juste bouclé la boucle plus serré que ce que j'avais vu ailleurs, parce que j'en avais besoin pour tenir le coup.

---

Le problème que je dogfoode en permanence

Tu connais le scénario si tu codes avec une IA:

Lundi:

• Tu expliques ton stack, tes décisions, tes pièges connus.
• L'IA code bien.

Mardi:

• « Continue où on en était. »
• L'IA: « Je n'ai pas de contexte sur votre projet… »
• Toi: 😤

Avec DockSky, j'ai inversé le truc. L'IA ne repart pas d'un chat vide. Elle interroge ma base structurée: projets, facettes, journal, décisions. Celle que j'utilise moi-même au quotidien.

Le dogfooding, c'est vérifier chaque jour que cette promesse tient debout.

---

Pas de chat dans l'app. Volontairement.

J'ai failli intégrer une fenêtre chat « Jarvis » dans l'app. Je l'ai supprimée.

Pourquoi ? Parce qu'un chat de plus, c'est une distraction de plus. Mon cerveau n'a pas besoin d'un endroit supplémentaire où aller perdre le fil.

L'IA vit dans Cursor, dans Copilot, dans Claude Desktop. DockSky, c'est la mémoire. Les facettes. Le journal. La roadmap. Le protocole de liaison entre l'humain et l'IA.

Le dialogue a lieu ailleurs. Le contexte, lui, reste chez moi.

---

Les facettes: mon invention à moi

Chaque projet a des facettes thématiques. Des fiches structurées avec des entrées typées:

• DECISION: ce qu'on a décidé et pourquoi
• TRAP: les pièges qu'on a déjà marchés
• TODO: ce qui reste à faire
• WORKS: ce qui fonctionne
• NOTE: le reste

Exemple concret: une facette « Infra VPS » avec les commandes SSH, les noms de containers Docker (et le piège service vs container, parce que j'ai cramé là-dessus), les TRAPs Orange DPI qui bloque le port 22.

Quand Cursor démarre une session, il charge cette facette via MCP. Il sait déjà que docker restart docksky_api_dev et pas pkill uvicorn. Sans que je le répète.

---

Un backend, plusieurs vies

Le truc que je n'avais pas prévu en dogfoodant: le même backend sert à des contextes très différents.

| Projet | Usage |

|--------|-------|

| DockSky (id 79) | Développement de l'app, infra, marketing |

| LRVB | Mon roman en cours |

| Dossiers perso | Organisation de dossiers complexes (juridique, etc.) |

Si l'architecture tient pour une API FastAPI et pour un roman et pour un dossier administratif, le modèle est solide. Le dogfooding multi-projets est un test de stress bien plus exigeant qu'un seul use case.

Et j'ai découvert en route que les facettes valent sans IA. J'ai organisé un dossier perso en fiches thématiques, consultables par moi seul, partageables avec l'IA seulement quand j'en ai besoin. L'outil sert d'abord à structurer ma pensée. L'IA, c'est un bonus.

---

La boucle fermée

Voici ce qui rend mon dogfooding différent de « j'utilise mon app de temps en temps »:

Je code → commit git → hook post-commit → entrée journal DockSky
                                              ↓
L'IA lit le journal + les facettes ← MCP ← je reprends le lendemain
                                              ↓
L'IA met à jour current_status + notes facettes en fin de session

Le développement alimente l'app automatiquement. L'historique de construction est capturé sans effort manuel.

Pour un cerveau TDA, c'est crucial. « Ne pas oublier de mettre à jour la doc » est exactement le problème que je résous. Si la doc ne se met pas à jour toute seule quand je code, elle ne se mettra pas à jour du tout.

J'ai même un script backfill_dogfooding.py qui crée rétroactivement des actions DONE dans ma roadmap à partir des commits fix. Le dogfooding laisse des traces structurées, pas juste un historique git illisible.

---

Dogfooding infra inclus

Ca ne s'arrête pas à l'app desktop.

J'ai dogfoodé Synapse: exécuter des commandes sur mon VPS via MCP, avec les secrets résolus depuis un coffre, sans coller le mot de passe MySQL dans le chat Cursor.

Test de référence validé:

mysql -uroot -p"{{MYSQL_ROOT}}" -e "SHOW DATABASES"

Machine docksky-vps, container ctn_mysql, secret MYSQL_ROOT dans le coffre. L'IA exécute. Moi je ne vois jamais le mot de passe dans la conversation.

Le dogfooding devient opérationnel. Pas une démo propre dans un slide deck.

---

Dogfooding honnête, pas performatif

Sur le site je dis « 18 mois de dogfooding quotidien ». Ce n'est pas du marketing.

• Mes tests API frappent un VPS réel, zéro mock
• Orange DPI bloque parfois le port 22: j'ai dû monter wstunnel pour SSH over WebSocket
• Les tokens MCP expirent, les quotas se remplissent, les rate limits mordent
• Chaque TRAP rencontré entre dans une facette, pas dans un ticket oublié

Si ça casse chez moi, ça entre dans le produit. C'est la seule beta test honnête que je connaisse quand tu es solo.

---

Ce que j'ai appris en 18 mois

1. Les facettes ont une valeur standalone.

Organiser un projet complexe en fiches thématiques, même sans IA, change la donne. L'IA amplifie, mais la structure vient d'abord.

2. Le bon niveau de persistance, c'est la base de données, pas les fichiers markdown.

J'ai commencé avec un dossier /AI/memory/ de fichiers markdown. Ca marchait, jusqu'au moment où les fichiers se désynchronisaient du code réel. Aujourd'hui c'est la même base que j'utilise et que l'IA lit. Toujours à jour par construction.

3. L'IA est un partenaire de session, pas un chatbot intégré.

Elle charge le contexte en début de session, travaille, met à jour la mémoire en fin de session. Pas de fenêtre qui traîne en permanence dans l'app.

4. La confidentialité par projet compte.

Chaque projet a un réglage ai_access (READ / WRITE / NONE). Mon roman n'est pas visible par le token MCP de DockSky. Le dogfooding inclut le respect de mes propres frontières.

---

Ce que ce n'est pas

• Ce n'est pas « une app TDAH ». Mon origine personnelle explique le design, pas le positionnement commercial.
• Ce n'est pas un SaaS cloud. C'est une app desktop Windows/Linux avec sync cloud.
• Ce n'est pas encore lancé publiquement. On est en beta, build in public.

---

Pourquoi je raconte ça

Parce que le dogfooding le plus utile que j'ai vu, chez les solo devs, c'est rarement « j'utilise mon produit ». C'est « mon produit est le système nerveux de ma façon de travailler avec une IA ».

Si tu codes seul, si tu jongles entre plusieurs projets, si tu en as marre de réexpliquer ton contexte à chaque session: c'est exactement le problème que je dogfoode depuis 18 mois.

Si ça résonne, le plan Free est sur [docksky.fr](https://docksky.fr). La doc MCP pour brancher Cursor ou Claude: [docksky.fr/mcp](https://docksky.fr/mcp). Les retours m'intéressent vraiment, je suis solo.