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.

01

Apprendre

02

Construire

03

Observer

04

Documenter

05

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.

  1. 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 →
  2. 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 →
  3. 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 →
  4. 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 →
  5. 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 →
  6. 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 →
  7. 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 →
  8. 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 →
  9. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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.