Sachez comment le travail se déroule avant de vous engager.

• Un produit complet à construire : périmètre, interface, backend, intégrations, déploiement et passation, pris en charge de bout en bout.
• Un produit existant dont une partie bloque le reste, et dont la partie bloquante descend sous la couche applicative.
• Une surface d'IA ou d'automatisation qui doit survivre à l'usage réel : limites des outils, évaluation, et un chemin défini en cas de défaillance.
• Des outils internes et des logiciels opérationnels sur lesquels une entreprise repose réellement, et non une preuve de concept.
• Une refonte où le système actuel est assez bien compris pour dire ce qui doit y survivre.

• Le problème, pas la solution

  Ce qui est cassé, lent, bloqué ou manquant, décrit de l'extérieur. La solution envisagée est utile plus tard ; la contrainte, c'est ce à partir de quoi le périmètre se construit.

• Qui l'exploite

  Qui utilise le système et ce que ces personnes cherchent à accomplir. Une surface produit conçue sans cela est une supposition recouverte d'un système de design.

• Ce qui tourne déjà

  La pile actuelle, où elle est hébergée, et ce qui ne peut pas changer. Les contraintes existantes façonnent l'architecture bien plus que les préférences.

• L'échéance réelle

  Ce qui détermine réellement la date : un lancement, un contrat, une migration, un audit. Une date qui a une raison derrière elle peut être planifiée.

• Limites d'accès et de conformité

  Tout ce qui régit qui peut toucher à la production, où les données peuvent résider, et ce qui doit être signé avant le début du travail.

• Comment la décision se prend

  Qui signe, quelle fourchette de budget est réaliste, et ce qui est évalué par ailleurs. Cela raccourcit tout ce qui suit.

Vous pouvez aussi le lire directement. Les quatre modèles sont présentés côte à côte sur la page des services, et les sept étapes du premier contact à la passation figurent plus bas sur celle-ci.

C'est le chemin que suit une mission, publié comme l'engagement pris plutôt que résumé après coup. C'est le processus auquel vous pourriez nous tenir.

1. 01

   Contact

   Un brief ou un appel. Le brief convient à un périmètre arrêté ; l'appel convient à un problème qui prend encore forme. Dans les deux cas, vous joignez la personne responsable du cadrage du travail.

2. 02

   Découverte

   Une ou deux séances de travail sur les contraintes plutôt que sur les fonctionnalités : ce qui tourne aujourd'hui, où cela fait mal, quels risques comptent en premier, et ce qui doit être vrai à la fin. Aucun engagement de part ni d'autre pour l'instant.

3. 03

   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, les hypothèses dont il dépend, et les critères de recette de chaque étape. Rien n'est facturé tant que ce document n'est pas validé, et s'il montre que ce n'est pas la bonne entreprise qui porte le travail, il le dit.

4. 04

   Proposition

   Le périmètre chiffré selon l'un des modèles de mission, avec l'échéancier de paiement, les hypothèses qui changeraient le montant, et ce qui est explicitement exclu. Un prix annoncé avant que le périmètre soit compris est une supposition en costume-cravate.

5. 05

   Construction par étapes

   Le travail est livré par incréments vérifiables selon le périmètre validé. Chaque étape livre quelque chose d'utilisable et est contrôlée par rapport à ses critères de recette, plutôt que de s'accumuler vers une seule livraison à la fin.

6. 06

   Recette

   Une étape est terminée quand elle satisfait les critères écrits pour elle, pas quand elle est déclarée terminée. Tout ce qui échoue à la recette est corrigé dans l'étape, et tout ce qui est découvert sans avoir jamais été dans le périmètre devient une décision explicite plutôt qu'un travail supplémentaire fait en silence.

7. 07

   Passation

   Le code source dans vos dépôts, l'infrastructure dans vos comptes, les notes d'architecture, les runbooks, les décisions et les alternatives écartées, et les limites connues. Le critère : un ingénieur qui n'a pas participé à la réalisation peut-il la reprendre sans négociation ?

• À l'écrit par défaut

  L'avancement, les décisions et les blocages par écrit, selon un rythme convenu au lancement. Les appels servent à ce que l'écrit fait mal : le désaccord, l'ambiguïté et la conception.

• Un point de contrôle planifié

  Un appel régulier dans votre fuseau horaire, plus ce dont le travail a besoin. Ce point existe pour qu'un problème n'attende jamais le prochain compte rendu d'avancement.

• Revue d'étape

  Chaque étape est revue par rapport à ses critères de recette à mesure qu'elle arrive, de sorte que la qualité est contrôlée en continu plutôt que découverte à la fin.

• Décisions consignées

  Les décisions d'architecture sont écrites au moment où elles sont prises, avec les alternatives écartées. Cette trace fait partie de ce que vous payez.

• Un accord de confidentialité peut être signé avant que le moindre détail soit discuté. Envoyez le vôtre, ou demandez-en un et un accord mutuel vous est fourni.
• Vous possédez le code et la propriété intellectuelle produite dans le cadre de la mission. C'est écrit dans le document de mission, pas supposé.
• L'accès suit le moindre privilège et se limite au travail en cours, demandé par système plutôt qu'accordé largement au lancement, et rendu à la fin.
• Les identifiants restent dans votre coffre de secrets. Jamais dans le code source, jamais dans un fil de discussion, jamais dans un ticket.
• L'infrastructure tourne dans vos comptes et le code source vit dans vos dépôts : révoquer l'accès est quelque chose que vous pouvez faire sans demander.
• Quand une réalisation a réellement besoin d'un spécialiste, cette personne est nommée pendant le cadrage, approuvée par vous, et affectée à cette partie du projet sous le même accord de confidentialité et les mêmes règles d'accès. Pas d'externalisation, pas de passage de relais à une agence, pas d'intermédiaire de place de marché, et un seul responsable tout au long.
• La facturation se fait par jalon selon l'échéancier convenu, dans votre devise lorsque les circuits de paiement le permettent.
• À distance en priorité, à l'échelle mondiale. La plage horaire commune est convenue au lancement plutôt que supposée.

• Un travail chiffré avant tout sur le fait d'être l'option la moins chère. L'ingénierie qui fait durer un système ne survit pas à cette contrainte.
• 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.
• Tout ce qui exige une échéance que le périmètre ne peut pas soutenir. Une date qui ne peut être tenue qu'en sautant les parties qui font tenir le système ne vaut pas d'être convenue.
• Un travail où personne de votre côté ne peut prendre de décision. Une mission sans interlocuteur capable de dire oui cale à la première bifurcation.

• PageConfiance et donnéesLes réponses pour une évaluation de fournisseur : les sous-traitants ultérieurs derrière ce site et ce que chacun détient, combien de temps un envoi est conservé, et les informations sur l'entité enregistrée que demande un dossier de référencement fournisseur.
• PageSécuritéL'ingénierie derrière le cadre commercial : moindre privilège, où vivent les identifiants, ce qu'un agent ou une intégration peut toucher, et comment signaler une vulnérabilité.
• DocumentsExemples de livrablesLes documents nommés juste au-dessus, publiés comme de vrais formats : ce que chacun consigne, à quel moment de la séquence il arrive, et le risque qu'il écarte.