Le produit entier, ou la partie qui le bloque.

• Un produit qui n'existe pas encore, où la difficulté n'est pas l'interface et où vous voulez une seule équipe responsable de l'ensemble.
• Un produit existant dont un composant bloque le reste, et dont la partie bloquante descend sous la couche applicative.
• Une refonte où le système actuel est assez bien compris pour dire ce qui doit y survivre.
• Un logiciel interne ou opérationnel sur lequel une entreprise repose réellement, et non une preuve de concept.
• Une équipe qui a la surface en main et qui a besoin que le backend, le modèle de données et le chemin de déploiement soient construits correctement dessous.

Une architecture de référence, c'est-à-dire la forme sur laquelle le travail est conçu, et non un relevé de systèmes livrés. Elle nomme des couches et des responsabilités, jamais des produits : ce qui tourne à une couche donnée est une décision prise avec vous pendant le cadrage, pas ici à l'avance.

• Un périmètre écrit : le problème tel qu'il est compris, ce qui sera construit et ce qui ne le sera pas, les étapes, et les critères de recette de chacune.
• Une note d'architecture portant les décisions, les alternatives étudiées et les conditions qui justifieraient d'en rouvrir une.
• L'interface et l'application frontend, construites sur des états réels plutôt que sur le chemin idéal.
• Des services backend et des API, avec le modèle de données et les intégrations derrière.
• Un chemin de déploiement du commit au service en fonctionnement, avec un retour arrière éprouvé.
• Un runbook et un dossier de passation : comment l'exploiter, comment il tombe en panne, et ce qui reste volontairement manuel.

• S'engager sur un chiffre avant que quiconque ait convenu de ce qu'est le travail, et c'est précisément là que les réalisations à prix fixe échouent d'ordinaire.
• Une zone grise entre prestataires où le frontend accuse le backend et où le problème difficile n'appartient à aucun des deux.
• Hériter d'un système que personne ne sait expliquer, où chaque changement futur commence par des fouilles archéologiques.
• Un produit fini qui ne fonctionne que tant que les personnes qui l'ont construit sont disponibles.
• Découvrir pendant un incident que le chemin de retour arrière était théorique.

• Les missions de design seul. L'interface est construite ici, mais une maquette sans système dessous relève de l'offre de quelqu'un d'autre.
• Un prix fixe sur un périmètre que personne n'a encore écrit. Le cadrage vient d'abord, et c'est un vrai travail.
• De la régie à l'heure sans résultat défini, où la mission est un siège plutôt qu'un résultat.
• Une échéance que le périmètre ne peut pas soutenir. Une date tenue en sautant les parties qui font tenir le système ne vaut pas d'être convenue.
• Les refontes où le système existant n'est pas assez bien compris pour dire ce qui doit y survivre. C'est de la découverte, et cela se cadre comme de la découverte.

1. 01

   Le code source dans vos dépôts

   Le code vit dans votre organisation dès le premier commit, pas chez nous avant d'être copié à la fin. Vous possédez le code et la propriété intellectuelle produite dans le cadre de la mission, et cela est écrit dans le document de mission plutôt que supposé.

2. 02

   L'infrastructure dans vos comptes

   Tout tourne dans des comptes que vous contrôlez, provisionnés en code pour qu'un environnement puisse être reconstruit depuis les sources plutôt que retenu de mémoire. Révoquer notre accès est une chose que vous pouvez faire sans demander.

3. 03

   Le raisonnement, écrit au fil de l'eau

   La note d'architecture, les décisions et les alternatives écartées, consignées quand elles étaient fraîches plutôt que reconstituées à la fin. C'est la partie que l'on perd d'ordinaire, et celle qui rend le changement suivant peu coûteux.

4. 04

   Un runbook pour ce qu'il faut exploiter

   Les tâches courantes, les modes de défaillance et leurs réponses, l'emplacement des journaux, ce qui reste volontairement manuel et les limites connues. Écrit pour quelqu'un qui n'était pas là.

• RéalisationUne plateforme de contenu multi-locataireUne surface produit lue comme une classe de problèmes : un modèle de création, et garder la sortie publiée en accord avec lui.
• DocumentsExemples de livrablesLe document de cadrage, la note d'architecture, le runbook et le dossier de passation, présentés comme les formats que vous recevriez.
• MéthodeComment se déroule une missionDécouverte, périmètre écrit, jalons, recette et passation, publiés avant le premier appel.