BUILD OS · BUILD → VERIFY → LEARN
Du prototype à un logiciel fiable, étape par étape.
Le Build OS relie opportunité, produit, ingénierie et exploitation. Chaque étape définit un objectif, des questions, des contrôles et une condition de sortie. Les builds et notes publiés forment une base de preuves documentées; les observations privées ne deviennent jamais des statistiques publiques par défaut.
La boucle
Construire → mesurer → codifier → mieux construire.
Une leçon n’entre dans le système que si elle est reliée à un contexte et une source. Un projet membre reste privé. Les benchmarks publics attendront un échantillon assez large et une méthode publiée.
Apprendre
Construire
Observer
Documenter
Réutiliser
22 étapes · une séquence
Le cycle complet d’un produit.
Les étapes sont un cadre de décision, pas une checklist linéaire obligatoire. Reviens en arrière quand une mesure contredit l’hypothèse.
- 01 · opportunityLien ↗
Opportunité
Partir d’un déclencheur identifiable et d’un travail qui mérite une solution.
Questions de décision
- — Qui rencontre le problème ?
- — Quel événement le rend urgent ?
- — Que fait cette personne aujourd’hui ?
À vérifier
- □ Décrire un utilisateur précis.
- □ Nommer un déclencheur observable.
- □ Identifier une alternative et son coût.
Piège courant
Prendre une catégorie de marché pour une demande validée.
Signal à suivre
Conversations où le problème est décrit sans suggestion.
Critère de sortie
Un segment, un déclencheur et une alternative sont documentés.
Prompt de revue + gabarit de décision
Agis comme reviewer critique de l’étape « Opportunité ». Objectif : Partir d’un déclencheur identifiable et d’un travail qui mérite une solution. Questions : Qui rencontre le problème ? · Quel événement le rend urgent ? · Que fait cette personne aujourd’hui ? Sépare les faits vérifiés, hypothèses et inconnues. Ne fabrique pas de preuve. Propose le plus petit prochain test, un résultat qui invaliderait l’hypothèse et une décision de sortie. Contexte / source : [lien ou observation] Résultat observé : [fait, mesure et période] Décision : [continuer, modifier, arrêter] Prochaine action : [responsable et échéance]
Exemple documenté : Atamatax structure des obligations autour de situations et de produits financiers précis.
Ressource liée → - 02 · validationLien ↗
Validation
Réduire l’incertitude avant d’engager du temps de développement.
Questions de décision
- — Quelle hypothèse pourrait invalider le projet ?
- — Quel comportement compte comme preuve ?
- — Quelle expérience est la moins coûteuse ?
À vérifier
- □ Écrire une hypothèse falsifiable.
- □ Choisir une observation plutôt qu’un avis.
- □ Fixer une durée et une règle d’arrêt.
Piège courant
Confondre intérêt poli, inscription et usage répété.
Signal à suivre
Comportement cible observé / personnes exposées.
Critère de sortie
Une hypothèse a un résultat observé et une décision associée.
Prompt de revue + gabarit de décision
Agis comme reviewer critique de l’étape « Validation ». Objectif : Réduire l’incertitude avant d’engager du temps de développement. Questions : Quelle hypothèse pourrait invalider le projet ? · Quel comportement compte comme preuve ? · Quelle expérience est la moins coûteuse ? Sépare les faits vérifiés, hypothèses et inconnues. Ne fabrique pas de preuve. Propose le plus petit prochain test, un résultat qui invaliderait l’hypothèse et une décision de sortie. Contexte / source : [lien ou observation] Résultat observé : [fait, mesure et période] Décision : [continuer, modifier, arrêter] Prochaine action : [responsable et échéance]
Exemple documenté : Les cas publiés distinguent explicitement ce qui est observable de ce qui reste une hypothèse.
Ressource liée → - 03 · positioningLien ↗
Positionnement
Expliquer pour qui le produit existe, quelle tâche il résout et pourquoi maintenant.
Questions de décision
- — Qui est le premier utilisateur ?
- — Quel résultat concret obtient-il ?
- — Quelle alternative remplace-t-on ?
À vérifier
- □ Écrire la promesse sans jargon.
- □ Nommer la limite du produit.
- □ Vérifier la formulation avec des utilisateurs.
Piège courant
Décrire les fonctionnalités avant le résultat.
Signal à suivre
Compréhension du message après une lecture sans explication.
Critère de sortie
Un utilisateur cible reconnaît son problème et la prochaine étape.
Prompt de revue + gabarit de décision
Agis comme reviewer critique de l’étape « Positionnement ». Objectif : Expliquer pour qui le produit existe, quelle tâche il résout et pourquoi maintenant. Questions : Qui est le premier utilisateur ? · Quel résultat concret obtient-il ? · Quelle alternative remplace-t-on ? Sépare les faits vérifiés, hypothèses et inconnues. Ne fabrique pas de preuve. Propose le plus petit prochain test, un résultat qui invaliderait l’hypothèse et une décision de sortie. Contexte / source : [lien ou observation] Résultat observé : [fait, mesure et période] Décision : [continuer, modifier, arrêter] Prochaine action : [responsable et échéance]
Exemple documenté : Les pages projet séparent le problème, le système et sa limite.
Ressource liée → - 04 · offerLien ↗
Offre
Relier le résultat promis, le périmètre, le prix et le mode de livraison.
Questions de décision
- — Que reçoit exactement le client ?
- — Qu’est-ce qui n’est pas inclus ?
- — Quel risque reste à la charge de chacun ?
À vérifier
- □ Définir livrables et conditions.
- □ Choisir un modèle adapté à la fréquence du besoin.
- □ Présenter le prix avant paiement.
Piège courant
Vendre un résultat garanti quand l’issue dépend de tiers ou de données manquantes.
Signal à suivre
Taux d’acceptation des offres qualifiées.
Critère de sortie
Un acheteur peut évaluer périmètre, prix et responsabilités.
Prompt de revue + gabarit de décision
Agis comme reviewer critique de l’étape « Offre ». Objectif : Relier le résultat promis, le périmètre, le prix et le mode de livraison. Questions : Que reçoit exactement le client ? · Qu’est-ce qui n’est pas inclus ? · Quel risque reste à la charge de chacun ? Sépare les faits vérifiés, hypothèses et inconnues. Ne fabrique pas de preuve. Propose le plus petit prochain test, un résultat qui invaliderait l’hypothèse et une décision de sortie. Contexte / source : [lien ou observation] Résultat observé : [fait, mesure et période] Décision : [continuer, modifier, arrêter] Prochaine action : [responsable et échéance]
Exemple documenté : Atamatax présente des parcours et prix distincts pour le libre-service, l’export et l’accompagnement.
Ressource liée → - 05 · productLien ↗
Produit
Définir le plus petit flux complet qui délivre le résultat utile.
Questions de décision
- — Quel est le premier résultat de l’utilisateur ?
- — Quelles données sont nécessaires ?
- — Où faut-il une règle déterministe ou une revue humaine ?
À vérifier
- □ Tracer le flux principal.
- □ Lister entrées, états et erreurs.
- □ Séparer faits, hypothèses et décisions.
Piège courant
Construire une collection de fonctionnalités avant de tester le flux.
Signal à suivre
Taux d’achèvement du travail principal.
Critère de sortie
Un parcours complet peut être exécuté de bout en bout.
Prompt de revue + gabarit de décision
Agis comme reviewer critique de l’étape « Produit ». Objectif : Définir le plus petit flux complet qui délivre le résultat utile. Questions : Quel est le premier résultat de l’utilisateur ? · Quelles données sont nécessaires ? · Où faut-il une règle déterministe ou une revue humaine ? Sépare les faits vérifiés, hypothèses et inconnues. Ne fabrique pas de preuve. Propose le plus petit prochain test, un résultat qui invaliderait l’hypothèse et une décision de sortie. Contexte / source : [lien ou observation] Résultat observé : [fait, mesure et période] Décision : [continuer, modifier, arrêter] Prochaine action : [responsable et échéance]
Exemple documenté : Le Tax Situation Engine montre la relation entre situation, règles et parcours.
Ressource liée → - 06 · uxLien ↗
UX
Rendre les choix, conséquences, limites et prochaines actions compréhensibles.
Questions de décision
- — Que sait l’utilisateur à chaque étape ?
- — Que se passe-t-il en cas d’erreur ?
- — Comment reprend-il un travail interrompu ?
À vérifier
- □ Concevoir états vide, chargement, succès et erreur.
- □ Rendre les incertitudes visibles.
- □ Tester clavier, mobile et contenu long.
Piège courant
Optimiser l’apparence sans vérifier la compréhension du flux.
Signal à suivre
Temps et abandons par étape critique.
Critère de sortie
Un nouvel utilisateur termine le flux sans aide non prévue.
Prompt de revue + gabarit de décision
Agis comme reviewer critique de l’étape « UX ». Objectif : Rendre les choix, conséquences, limites et prochaines actions compréhensibles. Questions : Que sait l’utilisateur à chaque étape ? · Que se passe-t-il en cas d’erreur ? · Comment reprend-il un travail interrompu ? Sépare les faits vérifiés, hypothèses et inconnues. Ne fabrique pas de preuve. Propose le plus petit prochain test, un résultat qui invaliderait l’hypothèse et une décision de sortie. Contexte / source : [lien ou observation] Résultat observé : [fait, mesure et période] Décision : [continuer, modifier, arrêter] Prochaine action : [responsable et échéance]
Exemple documenté : Les pages Horvera alignent périmètre affiché et règles du produit.
Ressource liée → - 07 · architectureLien ↗
Architecture
Choisir des frontières qui rendent les changements et les règles explicables.
Questions de décision
- — Quelles règles déterminent le résultat ?
- — Quelles données sont la source de vérité ?
- — Quelles opérations ne doivent jamais être côté client ?
À vérifier
- □ Définir modèles et contraintes.
- □ Tracer lecture/écriture par rôle.
- □ Versionner les règles à rejouer.
Piège courant
Choisir une architecture par popularité sans relier choix et contraintes.
Signal à suivre
Changements métier traçables aux règles et données.
Critère de sortie
Les composants, données et responsabilités sont explicités.
Prompt de revue + gabarit de décision
Agis comme reviewer critique de l’étape « Architecture ». Objectif : Choisir des frontières qui rendent les changements et les règles explicables. Questions : Quelles règles déterminent le résultat ? · Quelles données sont la source de vérité ? · Quelles opérations ne doivent jamais être côté client ? Sépare les faits vérifiés, hypothèses et inconnues. Ne fabrique pas de preuve. Propose le plus petit prochain test, un résultat qui invaliderait l’hypothèse et une décision de sortie. Contexte / source : [lien ou observation] Résultat observé : [fait, mesure et période] Décision : [continuer, modifier, arrêter] Prochaine action : [responsable et échéance]
Exemple documenté : Horvera partage ses données de référence entre pages et moteur.
Ressource liée → - 08 · buildLien ↗
Construction
Livrer le flux validé avec petits changements réversibles.
Questions de décision
- — Quel incrément peut être livré aujourd’hui ?
- — Comment vérifier le comportement ?
- — Comment revenir en arrière ?
À vérifier
- □ Découper par parcours utilisateur.
- □ Vérifier les états limites.
- □ Documenter décisions structurantes.
Piège courant
Laisser un agent ou un générateur modifier des frontières sans revue.
Signal à suivre
Flux terminés et défauts significatifs par incrément.
Critère de sortie
Le chemin principal fonctionne dans l’environnement cible.
Prompt de revue + gabarit de décision
Agis comme reviewer critique de l’étape « Construction ». Objectif : Livrer le flux validé avec petits changements réversibles. Questions : Quel incrément peut être livré aujourd’hui ? · Comment vérifier le comportement ? · Comment revenir en arrière ? Sépare les faits vérifiés, hypothèses et inconnues. Ne fabrique pas de preuve. Propose le plus petit prochain test, un résultat qui invaliderait l’hypothèse et une décision de sortie. Contexte / source : [lien ou observation] Résultat observé : [fait, mesure et période] Décision : [continuer, modifier, arrêter] Prochaine action : [responsable et échéance]
Exemple documenté : Les projets documentent les systèmes réels et leurs responsabilités.
Ressource liée → - 09 · securityLien ↗
Sécurité
Protéger identités, données, paiements et opérations sensibles.
Questions de décision
- — Qui peut lire ou modifier chaque enregistrement ?
- — Où sont les secrets ?
- — Comment détecter une mutation anormale ?
À vérifier
- □ Vérifier autorisation côté serveur et RLS.
- □ Valider entrées et webhooks.
- □ Limiter données, accès et rétention.
Piège courant
Prendre la présence d’un login pour une preuve d’autorisation.
Signal à suivre
Chemins sensibles couverts par des contrôles vérifiables.
Critère de sortie
Les accès privés sont testés par propriétaire, rôle et absence de session.
Prompt de revue + gabarit de décision
Agis comme reviewer critique de l’étape « Sécurité ». Objectif : Protéger identités, données, paiements et opérations sensibles. Questions : Qui peut lire ou modifier chaque enregistrement ? · Où sont les secrets ? · Comment détecter une mutation anormale ? Sépare les faits vérifiés, hypothèses et inconnues. Ne fabrique pas de preuve. Propose le plus petit prochain test, un résultat qui invaliderait l’hypothèse et une décision de sortie. Contexte / source : [lien ou observation] Résultat observé : [fait, mesure et période] Décision : [continuer, modifier, arrêter] Prochaine action : [responsable et échéance]
Exemple documenté : La checklist de readiness sépare authentification, autorisation, paiements et sauvegardes.
Ressource liée → - 10 · analyticsLien ↗
Analytics
Mesurer les actions qui changent une décision produit ou commerciale.
Questions de décision
- — Quel événement prouve la valeur ?
- — Quel échec doit être détecté ?
- — Quelles données sont superflues ou sensibles ?
À vérifier
- □ Définir noms et propriétés utiles.
- □ Éviter secrets et texte libre sensible.
- □ Associer chaque événement à une question.
Piège courant
Collecter des événements de vanité sans décision derrière.
Signal à suivre
Couverture des étapes utiles et des erreurs critiques.
Critère de sortie
Un funnel et un propriétaire d’action sont définis.
Prompt de revue + gabarit de décision
Agis comme reviewer critique de l’étape « Analytics ». Objectif : Mesurer les actions qui changent une décision produit ou commerciale. Questions : Quel événement prouve la valeur ? · Quel échec doit être détecté ? · Quelles données sont superflues ou sensibles ? Sépare les faits vérifiés, hypothèses et inconnues. Ne fabrique pas de preuve. Propose le plus petit prochain test, un résultat qui invaliderait l’hypothèse et une décision de sortie. Contexte / source : [lien ou observation] Résultat observé : [fait, mesure et période] Décision : [continuer, modifier, arrêter] Prochaine action : [responsable et échéance]
Exemple documenté : Build School suit création de projet, progression et étapes d’activation.
Ressource liée → - 11 · launchLien ↗
Lancement
Rendre le produit accessible, supportable et mesurable pour de vrais utilisateurs.
Questions de décision
- — Qui peut utiliser le produit maintenant ?
- — Comment signaler et corriger un problème ?
- — Quel périmètre est explicitement limité ?
À vérifier
- □ Vérifier domaine, sauvegardes et alertes.
- □ Préparer support et rollback.
- □ Tester le parcours avec une personne externe.
Piège courant
Traiter le déploiement comme une fin plutôt que le début de l’apprentissage.
Signal à suivre
Utilisateurs qui terminent le flux cible.
Critère de sortie
Une version déployée a un propriétaire, un signal et un chemin de récupération.
Prompt de revue + gabarit de décision
Agis comme reviewer critique de l’étape « Lancement ». Objectif : Rendre le produit accessible, supportable et mesurable pour de vrais utilisateurs. Questions : Qui peut utiliser le produit maintenant ? · Comment signaler et corriger un problème ? · Quel périmètre est explicitement limité ? Sépare les faits vérifiés, hypothèses et inconnues. Ne fabrique pas de preuve. Propose le plus petit prochain test, un résultat qui invaliderait l’hypothèse et une décision de sortie. Contexte / source : [lien ou observation] Résultat observé : [fait, mesure et période] Décision : [continuer, modifier, arrêter] Prochaine action : [responsable et échéance]
Exemple documenté : Les études de cas distinguent produit en production, bêta et expérimentation.
Ressource liée → - 12 · seoLien ↗
SEO
Répondre à une intention réelle avec une page reliée au produit et à des preuves.
Questions de décision
- — Quelle décision chercheur tente-t-il de prendre ?
- — Le produit peut-il satisfaire cette intention ?
- — Quelle preuve propre à cette page existe ?
À vérifier
- □ Créer une réponse autonome.
- □ Relier au bon outil, cas ou étape.
- □ Vérifier indexabilité et canonical.
Piège courant
Générer des pages proches sans information ou utilité distincte.
Signal à suivre
Impressions qualifiées, clics et actions utiles par cluster.
Critère de sortie
La page est utile seule, exacte et reliée au parcours.
Prompt de revue + gabarit de décision
Agis comme reviewer critique de l’étape « SEO ». Objectif : Répondre à une intention réelle avec une page reliée au produit et à des preuves. Questions : Quelle décision chercheur tente-t-il de prendre ? · Le produit peut-il satisfaire cette intention ? · Quelle preuve propre à cette page existe ? Sépare les faits vérifiés, hypothèses et inconnues. Ne fabrique pas de preuve. Propose le plus petit prochain test, un résultat qui invaliderait l’hypothèse et une décision de sortie. Contexte / source : [lien ou observation] Résultat observé : [fait, mesure et période] Décision : [continuer, modifier, arrêter] Prochaine action : [responsable et échéance]
Exemple documenté : Horvera documente la cohérence entre pages et moteur; Vellaci ses pages SEO techniques.
Ressource liée → - 13 · aeoLien ↗
AEO
Structurer les réponses pour les moteurs qui extraient et citent des passages.
Questions de décision
- — Quelle question précise la page résout-elle ?
- — La réponse directe est-elle explicite ?
- — Les termes et limites sont-ils définis ?
À vérifier
- □ Répondre tôt et précisément.
- □ Structurer définitions, étapes et exemples.
- □ Attribuer les affirmations et dates.
Piège courant
Ajouter des FAQ de remplissage ou un balisage non visible.
Signal à suivre
Questions couvertes par une réponse vérifiable.
Critère de sortie
Une réponse peut être extraite sans perdre son périmètre.
Prompt de revue + gabarit de décision
Agis comme reviewer critique de l’étape « AEO ». Objectif : Structurer les réponses pour les moteurs qui extraient et citent des passages. Questions : Quelle question précise la page résout-elle ? · La réponse directe est-elle explicite ? · Les termes et limites sont-ils définis ? Sépare les faits vérifiés, hypothèses et inconnues. Ne fabrique pas de preuve. Propose le plus petit prochain test, un résultat qui invaliderait l’hypothèse et une décision de sortie. Contexte / source : [lien ou observation] Résultat observé : [fait, mesure et période] Décision : [continuer, modifier, arrêter] Prochaine action : [responsable et échéance]
Exemple documenté : Les field notes séparent principe, contexte, application et vérification.
Ressource liée → - 14 · geoLien ↗
GEO
Donner aux systèmes génératifs des informations fiables, attribuables et cohérentes.
Questions de décision
- — Quelles entités et relations sont établies ?
- — Quelle source soutient chaque affirmation ?
- — Les données sont-elles cohérentes entre pages ?
À vérifier
- □ Utiliser noms et définitions stables.
- □ Relier auteur, projet et source.
- □ Maintenir robots, sitemap et données structurées exacts.
Piège courant
Chercher un raccourci de citation sans corpus fiable.
Signal à suivre
Exactitude et attribution des réponses observées.
Critère de sortie
Les faits clés sont corroborés par pages cohérentes et sources identifiées.
Prompt de revue + gabarit de décision
Agis comme reviewer critique de l’étape « GEO ». Objectif : Donner aux systèmes génératifs des informations fiables, attribuables et cohérentes. Questions : Quelles entités et relations sont établies ? · Quelle source soutient chaque affirmation ? · Les données sont-elles cohérentes entre pages ? Sépare les faits vérifiés, hypothèses et inconnues. Ne fabrique pas de preuve. Propose le plus petit prochain test, un résultat qui invaliderait l’hypothèse et une décision de sortie. Contexte / source : [lien ou observation] Résultat observé : [fait, mesure et période] Décision : [continuer, modifier, arrêter] Prochaine action : [responsable et échéance]
Exemple documenté : Le graphe public relie projets documentés et notes vérifiées.
Ressource liée → - 15 · croLien ↗
Conversion
Réduire les frictions entre valeur comprise et prochaine action choisie.
Questions de décision
- — Quelle action est la plus utile ici ?
- — Quelle objection empêche cette action ?
- — Le CTA correspond-il à l’intention ?
À vérifier
- □ Énoncer prix ou engagement.
- □ Répondre aux objections réelles.
- □ Mesurer les résultats qualifiés.
Piège courant
Optimiser le clic au détriment de la qualité ou de la confiance.
Signal à suivre
Action utile par visiteur qualifié.
Critère de sortie
Une hypothèse de conversion est testable sans masquer les conditions.
Prompt de revue + gabarit de décision
Agis comme reviewer critique de l’étape « Conversion ». Objectif : Réduire les frictions entre valeur comprise et prochaine action choisie. Questions : Quelle action est la plus utile ici ? · Quelle objection empêche cette action ? · Le CTA correspond-il à l’intention ? Sépare les faits vérifiés, hypothèses et inconnues. Ne fabrique pas de preuve. Propose le plus petit prochain test, un résultat qui invaliderait l’hypothèse et une décision de sortie. Contexte / source : [lien ou observation] Résultat observé : [fait, mesure et période] Décision : [continuer, modifier, arrêter] Prochaine action : [responsable et échéance]
Exemple documenté : Les expériences commerciales mesurent leads qualifiés et diagnostics, pas seulement les clics.
Ressource liée → - 16 · distributionLien ↗
Distribution
Trouver un canal reproductible qui atteint le segment au bon moment.
Questions de décision
- — Où le problème devient-il visible ?
- — Quel canal peut être appris à petite échelle ?
- — Que coûte une action qualifiée ?
À vérifier
- □ Choisir un canal initial.
- □ Associer contenu et intention.
- □ Suivre source jusqu’au résultat.
Piège courant
Être présent sur tous les canaux sans boucle mesurable.
Signal à suivre
Coût ou effort par utilisateur activé.
Critère de sortie
Un canal produit un signal qualifié que l’on peut répéter.
Prompt de revue + gabarit de décision
Agis comme reviewer critique de l’étape « Distribution ». Objectif : Trouver un canal reproductible qui atteint le segment au bon moment. Questions : Où le problème devient-il visible ? · Quel canal peut être appris à petite échelle ? · Que coûte une action qualifiée ? Sépare les faits vérifiés, hypothèses et inconnues. Ne fabrique pas de preuve. Propose le plus petit prochain test, un résultat qui invaliderait l’hypothèse et une décision de sortie. Contexte / source : [lien ou observation] Résultat observé : [fait, mesure et période] Décision : [continuer, modifier, arrêter] Prochaine action : [responsable et échéance]
Exemple documenté : Les projets documentent des stratégies de recherche comme choix de distribution, sans inventer de résultats.
Ressource liée → - 17 · salesLien ↗
Vente
Comprendre l’objection, la décision et le processus d’achat réel.
Questions de décision
- — Qui décide et qui utilise ?
- — Qu’est-ce qui bloque le passage à l’action ?
- — Quelle preuve réduit cette incertitude ?
À vérifier
- □ Capturer les objections sans donnée inutile.
- □ Définir critères de qualification.
- □ Fermer la boucle entre vente et produit.
Piège courant
Interpréter une demande de fonctionnalité isolée comme stratégie.
Signal à suivre
Étapes franchies par opportunité qualifiée.
Critère de sortie
Les objections récurrentes ont une réponse ou une décision produit.
Prompt de revue + gabarit de décision
Agis comme reviewer critique de l’étape « Vente ». Objectif : Comprendre l’objection, la décision et le processus d’achat réel. Questions : Qui décide et qui utilise ? · Qu’est-ce qui bloque le passage à l’action ? · Quelle preuve réduit cette incertitude ? Sépare les faits vérifiés, hypothèses et inconnues. Ne fabrique pas de preuve. Propose le plus petit prochain test, un résultat qui invaliderait l’hypothèse et une décision de sortie. Contexte / source : [lien ou observation] Résultat observé : [fait, mesure et période] Décision : [continuer, modifier, arrêter] Prochaine action : [responsable et échéance]
Exemple documenté : Le pipeline commercial existant structure qualification, diagnostic et proposition.
Ressource liée → - 18 · fulfillmentLien ↗
Livraison
Fournir le résultat promis avec un processus répétable et des limites claires.
Questions de décision
- — Quelles étapes nécessitent une personne ?
- — Quelles entrées sont requises ?
- — Comment sait-on que la livraison est complète ?
À vérifier
- □ Définir critères d’acceptation.
- □ Séparer automatisation et revue.
- □ Établir handoff et suivi.
Piège courant
Automatiser une étape dont les exceptions ne sont pas comprises.
Signal à suivre
Délai, reprises et livraisons conformes.
Critère de sortie
Le service ou produit a une définition de terminé vérifiable.
Prompt de revue + gabarit de décision
Agis comme reviewer critique de l’étape « Livraison ». Objectif : Fournir le résultat promis avec un processus répétable et des limites claires. Questions : Quelles étapes nécessitent une personne ? · Quelles entrées sont requises ? · Comment sait-on que la livraison est complète ? Sépare les faits vérifiés, hypothèses et inconnues. Ne fabrique pas de preuve. Propose le plus petit prochain test, un résultat qui invaliderait l’hypothèse et une décision de sortie. Contexte / source : [lien ou observation] Résultat observé : [fait, mesure et période] Décision : [continuer, modifier, arrêter] Prochaine action : [responsable et échéance]
Exemple documenté : Les systèmes documentés distinguent parcours autonome, export et accompagnement.
Ressource liée → - 19 · retentionLien ↗
Rétention
Faire revenir l’utilisateur parce que le produit reste utile dans son travail.
Questions de décision
- — À quelle fréquence le besoin revient-il ?
- — Quelle donnée historique aide réellement ?
- — Quel événement signale une perte de valeur ?
À vérifier
- □ Identifier moment de valeur récurrent.
- □ Mesurer retour et accomplissement.
- □ Permettre export et suppression des données.
Piège courant
Ajouter notifications pour compenser une faible valeur récurrente.
Signal à suivre
Rétention par cohorte et usage du flux cœur.
Critère de sortie
Une raison de retour est observée et liée au problème.
Prompt de revue + gabarit de décision
Agis comme reviewer critique de l’étape « Rétention ». Objectif : Faire revenir l’utilisateur parce que le produit reste utile dans son travail. Questions : À quelle fréquence le besoin revient-il ? · Quelle donnée historique aide réellement ? · Quel événement signale une perte de valeur ? Sépare les faits vérifiés, hypothèses et inconnues. Ne fabrique pas de preuve. Propose le plus petit prochain test, un résultat qui invaliderait l’hypothèse et une décision de sortie. Contexte / source : [lien ou observation] Résultat observé : [fait, mesure et période] Décision : [continuer, modifier, arrêter] Prochaine action : [responsable et échéance]
Exemple documenté : Founder Memory est à construire sur l’historique utile, avec contrôle de l’utilisateur.
Ressource liée → - 20 · automationLien ↗
Automatisation
Automatiser les opérations répétées une fois règles et exceptions comprises.
Questions de décision
- — Quel travail est réellement répétitif ?
- — Quelles exceptions doivent rester visibles ?
- — Comment corriger ou rejouer ?
À vérifier
- □ Mesurer travail manuel actuel.
- □ Définir idempotence et reprise.
- □ Tracer résultats et exceptions.
Piège courant
Automatiser une procédure instable ou non comprise.
Signal à suivre
Temps manuel et taux de reprise.
Critère de sortie
Le chemin automatisé est observable et récupérable.
Prompt de revue + gabarit de décision
Agis comme reviewer critique de l’étape « Automatisation ». Objectif : Automatiser les opérations répétées une fois règles et exceptions comprises. Questions : Quel travail est réellement répétitif ? · Quelles exceptions doivent rester visibles ? · Comment corriger ou rejouer ? Sépare les faits vérifiés, hypothèses et inconnues. Ne fabrique pas de preuve. Propose le plus petit prochain test, un résultat qui invaliderait l’hypothèse et une décision de sortie. Contexte / source : [lien ou observation] Résultat observé : [fait, mesure et période] Décision : [continuer, modifier, arrêter] Prochaine action : [responsable et échéance]
Exemple documenté : Les notes distinguent source de vérité, moteur de règles et revue humaine.
Ressource liée → - 21 · moatLien ↗
Défensibilité
Identifier ce qui s’améliore ou devient plus difficile à reproduire par l’usage.
Questions de décision
- — Quelle ressource s’accumule ?
- — Comment chaque usage améliore-t-il le résultat ?
- — Quels droits ou effets sont réellement durables ?
À vérifier
- □ Séparer actif existant et possibilité.
- □ Relier avantage à rétention ou distribution.
- □ Vérifier consentement et portabilité.
Piège courant
Appeler une fonctionnalité ou un slogan un moat.
Signal à suivre
Amélioration mesurée au fil des usages ou des cohortes.
Critère de sortie
Un mécanisme d’accumulation a preuve, boucle et limite documentées.
Prompt de revue + gabarit de décision
Agis comme reviewer critique de l’étape « Défensibilité ». Objectif : Identifier ce qui s’améliore ou devient plus difficile à reproduire par l’usage. Questions : Quelle ressource s’accumule ? · Comment chaque usage améliore-t-il le résultat ? · Quels droits ou effets sont réellement durables ? Sépare les faits vérifiés, hypothèses et inconnues. Ne fabrique pas de preuve. Propose le plus petit prochain test, un résultat qui invaliderait l’hypothèse et une décision de sortie. Contexte / source : [lien ou observation] Résultat observé : [fait, mesure et période] Décision : [continuer, modifier, arrêter] Prochaine action : [responsable et échéance]
Exemple documenté : SponsorsMetrics expose le problème de démarrage d’un produit dont la valeur dépend des données comparables.
Ressource liée → - 22 · scaleLien ↗
Échelle
Augmenter le volume sans dégrader qualité, économie ou confiance.
Questions de décision
- — Quel goulot est prouvé ?
- — Quelles unités économiques changent ?
- — Quels contrôles doivent suivre la croissance ?
À vérifier
- □ Repérer contrainte réelle.
- □ Mesurer marge et capacité.
- □ Automatiser après stabilisation.
Piège courant
Élargir le marché ou le volume avant d’avoir une boucle qui fonctionne.
Signal à suivre
Marge, activation, qualité et capacité par cohorte.
Critère de sortie
La boucle actuelle reste saine à une charge plus élevée.
Prompt de revue + gabarit de décision
Agis comme reviewer critique de l’étape « Échelle ». Objectif : Augmenter le volume sans dégrader qualité, économie ou confiance. Questions : Quel goulot est prouvé ? · Quelles unités économiques changent ? · Quels contrôles doivent suivre la croissance ? Sépare les faits vérifiés, hypothèses et inconnues. Ne fabrique pas de preuve. Propose le plus petit prochain test, un résultat qui invaliderait l’hypothèse et une décision de sortie. Contexte / source : [lien ou observation] Résultat observé : [fait, mesure et période] Décision : [continuer, modifier, arrêter] Prochaine action : [responsable et échéance]
Exemple documenté : Chaque projet a un statut publié; une phase de croissance n’est jamais présumée.
Ressource liée →
Problème → diagnostic → système
Relier la panne à la preuve.
Les pages problème expliquent les symptômes, le mécanisme, le correctif et sa vérification. Les patterns rendent les règles réutilisables; les builds et notes montrent leur provenance. ShipCheck aide à choisir la prochaine vérification, et Build School enseigne le système derrière le correctif.
Apprendre · construire · vérifier · livrer
Le Build OS rejoint Build School.
Dans l’espace membre, un projet, sa progression, ses audits et son historique privé donnent du contexte aux prochaines actions. Les champs actuels ne sont pas utilisés pour entraîner un modèle ni publiés comme étude de cas.