Livrez le code, pas la présentation

Rédigé par l’équipe d’ingénierie de Peculiar CloudPublié le Mis à jour le

Un livrable de consultation devrait compiler. La partie difficile, coûteuse et risquée du travail d’infrastructure, c’est la mise en œuvre — l’IAM qui applique réellement le moindre privilège, le réseau qui segmente réellement, le garde-fou qui refuse réellement. Une présentation qui s’arrête à la recommandation vous rend cette partie et vous facture la moitié facile. Nous terminons les mandats de construction d’infrastructure par un dépôt Terraform que votre équipe possède et exploite, parce que c’est la partie qui valait vraiment la peine d’être payée.

Il y a un tour de passe-passe discret dans une bonne partie de la consultation en infrastructure. Vous payez pour de l’expertise, et ce qui arrive, c’est un document décrivant ce que l’expertise ferait. La recommandation est le livrable. La construction — le moment où l’expertise est réellement confrontée à la réalité — est laissée en exercice à votre équipe, ou à la prochaine personne que vous embaucherez.

Le 80 % que la présentation escamote

Concevoir une zone d’atterrissage ou un modèle « zéro confiance » sur un tableau blanc, c’est le premier 20 % du travail. Le 80 % restant, c’est là que se trouve chaque décision intéressante :

  • La politique IAM qui semblait respecter le moindre privilège sur le diagramme et qui, en pratique, brise trois services.
  • Le SCP qui refuse la bonne chose sans refuser l’accès d’urgence.
  • La segmentation réseau qui doit survivre à une vraie table de routage, à un vrai résolveur DNS et à un vrai ingénieur de garde à 2 h du matin.
  • La douzaine de petites décisions de réversibilité qui déterminent si la bascule est sécuritaire.

Une diapositive dit « implémentez le zéro confiance ». Le code, c’est là que vous découvrez ce que ça coûte et ce que ça brise. S’arrêter à la diapositive n’est pas une version réduite du mandat — c’est le mandat moins la partie qui était difficile.

La « recommandation à bâtir » est un transfert de risque

Quand un livrable s’arrête à une recommandation, le risque de mise en œuvre ne disparaît pas. Il se transfère — à votre équipe, ou à un deuxième fournisseur qui doit maintenant faire de la rétro-ingénierie sur l’intention de quelqu’un d’autre. La firme qui a rédigé la présentation n’en porte aucune part. C’est une position confortable pour vendre et coûteuse pour acheter.

Ce que « le livrable compile » impose

Exiger qu’un mandat se termine par du code qui s’exécute change les incitatifs jusqu’au tout début :

  • Les décisions se prennent, elles ne se reportent pas — on ne peut pas remettre un dépôt rempli de « à déterminer ».
  • Les compromis se consignent sous forme d’ADR, parce que le prochain ingénieur (le vôtre) doit vivre avec.
  • Le travail est révisable au fur et à mesure — de petites PR contre votre CI — pour que rien n’arrive comme une boîte noire.
  • Le transfert est falsifiable : soit votre équipe peut l’appliquer, le détruire et l’étendre sans nous, soit il n’est pas terminé.

Le test que vous pouvez appliquer à n’importe quel fournisseur

Posez une seule question avant de signer : qu’y a-t-il, exactement, dans le dépôt quand vous partez ? Si la réponse honnête est « un rapport et une feuille de route », vous achetez le 20 % facile et vous gardez le 80 % difficile. Si c’est « du Terraform, l’ensemble de garde-fous, un modèle de menaces, des ADR et des guides d’exploitation — en exécution dans vos comptes », vous achetez la partie qui en valait la peine.

C’est tout notre mode de fonctionnement : nous livrons le code, pas la présentation.

Dites-nous ce qui se passe