La livraison arrive, le site fonctionne, la démonstration est convaincante. Le prestataire envoie la facture de solde. Et dans neuf cas sur dix, l’entreprise la paie après avoir cliqué une dizaine de minutes sur l’application. C’est le seul moment du projet où vous disposez d’un levier réel, et il est presque toujours gaspillé.
J’ai mené ou supervisé 23 recettes techniques depuis 2024, sur des livraisons allant de 15 000 à 240 000 EUR. Ce qui suit est la liste exacte des sept contrôles que j’exécute, dans l’ordre, avec les résultats observés. Elle prend deux à trois jours et doit être inscrite au contrat dès la signature — pas improvisée à la livraison, où elle passe pour de la défiance.
Précision utile : rien ici ne suppose que le prestataire soit malhonnête. Sur mes vingt-trois dossiers, je n’ai rencontré aucune fraude. J’ai rencontré de la précipitation de fin de projet, des conventions implicites jamais écrites, et des équipes qui ne savaient pas elles-mêmes ce qu’elles avaient livré.
Contrôle 1 : reconstruire le projet depuis un poste vierge
C’est le contrôle le plus simple, le plus rapide, et de loin le plus révélateur. Prenez une machine neuve — ou un conteneur vide — clonez le dépôt, et suivez le README à la lettre, sans aucune aide du prestataire. Chronométrez.
Sur mes vingt-trois recettes, ce contrôle a échoué quatorze fois. Les causes, par fréquence décroissante : une variable d’environnement non documentée, une version d’outil implicite (« ça marche avec la 20, pas la 22 »), une étape manuelle que quelqu’un avait faite une fois et jamais notée, et un accès à un registre privé jamais mentionné.
Pourquoi c’est décisif : si vous ne pouvez pas reconstruire le projet aujourd’hui, avec le prestataire encore joignable, vous ne le pourrez certainement pas dans dix-huit mois quand il aura changé d’activité. Un projet non reconstructible n’est pas un actif, c’est une location dont vous ignorez l’échéance.
Le critère de réussite est explicite : une personne compétente mais extérieure au projet obtient un environnement fonctionnel en moins de deux heures, en ne lisant que la documentation fournie.
Contrôle 2 : auditer les dépendances et leur provenance
Trois vérifications, chacune rapide.
Le fichier de verrouillage existe et est à jour. Sans lui, deux installations à quinze jours d’écart ne produisent pas le même logiciel, et toute reproduction de bug devient une loterie. Absent ou incohérent sur six de mes vingt-trois dossiers.
Les vulnérabilités connues sont traitées ou justifiées. Je ne demande jamais zéro alerte, ce serait irréaliste. Je demande que chaque alerte de sévérité haute soit soit corrigée, soit accompagnée d’une justification écrite d’une ligne. L’absence totale de position est le vrai signal.
Les licences sont compatibles avec votre usage. C’est le point le plus négligé et le plus coûteux à corriger tard. Une bibliothèque sous licence copyleft forte au cœur d’un produit que vous comptez commercialiser peut vous obliger à réécrire un module entier. Rencontré deux fois, dont une où la réécriture a coûté onze jours.
Sur la méthodologie complète d’audit de la chaîne d’approvisionnement logicielle — provenance des paquets, signatures, surveillance des versions publiées — l’approche de WebGuard Agency va plus loin que ce que couvre une recette de projet et mérite d’être branchée en continu après la livraison.
Contrôle 3 : chercher les secrets dans tout l’historique
Attention au piège : la plupart des gens scannent l’état courant du dépôt. C’est insuffisant. Un secret retiré du code reste présent dans l’historique des commits, et l’historique est ce que vous récupérez.
Neuf dépôts sur vingt-trois contenaient au moins un secret dans leur historique : clés d’API de services tiers, identifiants de base de données, jeton d’accès à un registre privé, et dans un cas un mot de passe d’administration encore valide au moment de l’audit.
La règle est sans nuance : tout secret trouvé dans l’historique est un secret compromis, même si le dépôt a toujours été privé. Il doit être rotaté avant la mise en production, et cette rotation figure comme réserve bloquante au procès-verbal.
Une livraison arrive bientôt chez vous ?
Nous exécutons les 7 contrôles sur le dépôt livré et vous rendons un procès-verbal de recette avec les réserves chiffrées et hiérarchisées.
Lance-toi — demander une recette techniqueContrôle 4 : vérifier que les tests testent quelque chose
Un taux de couverture est un chiffre, pas une garantie. Il mesure les lignes exécutées pendant la suite de tests, ce qui n’est pas du tout la même chose que les comportements vérifiés.
La méthode qui tranche en trente minutes : cassez volontairement trois fonctions métier — modifiez un calcul, inversez une condition, supprimez une validation — et relancez la suite. Si elle passe au vert, vos tests n’ont aucune valeur de protection, quel que soit le pourcentage affiché.
J’ai appliqué ce test de mutation manuel sur mes vingt-trois dossiers : huit suites ont continué à passer alors que du code métier était volontairement cassé. Deux d’entre elles affichaient plus de 80 % de couverture.
| Ce qu’on vous montre | Ce que ça prouve | Ce qu’il faut demander |
|---|---|---|
| « 85 % de couverture » | 85 % des lignes sont exécutées | Casser 3 fonctions et relancer |
| « La CI est verte » | La suite s’exécute sans erreur | Voir ce que la CI exécute vraiment |
| « Tout est testé » | Rien du tout | La liste des cas limites couverts |
| « On a fait de la recette manuelle » | Un test à un instant t | Le scénario écrit et rejouable |
Contrôle 5 : exiger la documentation d’exploitation
Ne demandez pas de la documentation de code — elle vieillit mal et le code sérieux se documente largement lui-même. Demandez la documentation d’exploitation, celle dont vous aurez besoin un dimanche soir.
Quatre documents, et ils tiennent chacun en une page :
- Procédure de déploiement — comment mettre en production, et surtout comment revenir en arrière. Le retour arrière est ce qui manque presque toujours.
- Procédure de restauration de sauvegarde — testée, avec la durée réelle constatée. Une sauvegarde jamais restaurée n’est pas une sauvegarde.
- Procédure de rotation des secrets — quels secrets existent, où ils vivent, comment les changer sans interruption de service.
- Carte des dépendances externes — quels services tiers sont appelés, avec quel compte, et ce qui casse si l’un d’eux tombe.
Absente ou gravement incomplète sur dix-sept de mes vingt-trois dossiers. C’est le record de la liste, et l’explication est simple : personne ne la demande jamais, donc personne ne la budgète.
Contrôle 6 : contrôler la propriété intellectuelle et les comptes
Vérification purement administrative, une heure, et pourtant dix anomalies sur vingt-trois dossiers.
Trois points à confirmer par écrit. Les comptes sont au nom du client : dépôt de code, nom de domaine, hébergement, services tiers payants. Un abonnement souscrit au nom du prestataire signifie que votre production dépend de sa santé financière. La cession de droits est explicite dans le contrat, et couvre le code produit spécifiquement pour vous. Les éléments réutilisés sont identifiés : la plupart des agences réemploient légitimement un socle interne, ce qui est sain à condition que la licence d’usage soit écrite plutôt que sous-entendue.
Contrôle 7 : écrire le procès-verbal de recette avec réserves chiffrées
C’est le seul livrable de la recette qui vous protège juridiquement, et le plus souvent négligé au profit d’un courriel de validation.
Le procès-verbal liste chaque réserve avec trois attributs obligatoires : sa gravité (bloquante, majeure, mineure), son délai de levée, et la fraction du solde qu’elle conditionne. Une réserve sans ces trois attributs n’est pas une réserve, c’est un commentaire.
La retenue qui fonctionne le mieux est de 20 % du montant total, inscrite au contrat initial et libérée en une fois à la levée de la totalité des réserves bloquantes. En dessous de 15 %, la pression est insuffisante. Au-dessus de 25 %, vous fragilisez la trésorerie de celui qui doit précisément corriger — ce qui se retourne contre vous.
Et une règle de conduite que j’ai apprise à mes dépens : ne bloquez jamais un solde sur des réserves mineures. Cela transforme un partenaire en adversaire pour un gain nul, et vous aurez besoin de ce partenaire pendant la garantie.
Le moment où vous tenez le solde est le seul de tout le projet où la documentation s’écrit vite et où les accès reviennent sans discussion. Ce qui n’est pas obtenu à cet instant précis ne sera jamais obtenu. — Panos Petropoulos, D-Open
Ce que ça a donné sur 23 recettes
Toutes réserves confondues, ces sept contrôles ont produit en moyenne 6,4 réserves par dossier, dont 1,8 bloquante. Délai médian de levée des réserves bloquantes : 12 jours. Aucun litige contentieux sur vingt-trois dossiers, et je crois que la raison tient au contrôle 7 : quand les réserves sont chiffrées et hiérarchisées dès le départ, la discussion porte sur des faits et non sur des impressions.
Un dernier constat, contre-intuitif : les prestataires avec lesquels nous avons continué à travailler le plus longtemps sont ceux dont la première recette a produit le plus de réserves. Une recette exigeante n’abîme pas la relation — elle établit un standard, et les équipes sérieuses s’y adaptent dès le projet suivant.
Si vous vous apprêtez à lancer un projet plutôt qu’à le réceptionner, notre guide pour créer un CRM sur mesure détaille les clauses à poser dès le cadrage, et celui consacré à la marketplace traite spécifiquement de la propriété du socle quand une agence réemploie ses propres composants. Sur la reprise d’un projet déjà livré et abandonné, l’analyse publiée par Plug-Tech complète utilement cette méthode côté systèmes à base d’IA.
Faites le contrôle 1 dès aujourd’hui
Même sur un projet livré il y a six mois : clonez le dépôt sur une machine vierge et suivez le README. Vous saurez en deux heures si vous possédez un actif ou une location.
Lance-toi — parler à un ingénieurFAQ : recette technique avant paiement du solde
Combien de temps faut-il prévoir pour la recette technique ?
Deux à trois jours pour un projet de taille moyenne, à prévoir au contrat dès la signature. Répartition typique : une demi-journée pour la reconstruction depuis un poste vierge, une demi-journée pour dépendances et secrets, une journée pour tests et documentation d’exploitation, une demi-journée pour la propriété intellectuelle et le procès-verbal. Un prestataire sérieux ne s’y oppose jamais.
Quelle part du budget retenir jusqu’à la levée des réserves ?
Entre 15 et 25 %, inscrit au contrat initial. En dessous de 15 %, la retenue ne pèse pas assez. Au-dessus de 25 %, vous fragilisez la trésorerie de celui qui doit corriger. La règle la plus efficace : 20 % libérés en une fois à la levée de toutes les réserves bloquantes.
Que faire si le prestataire refuse la recette technique ?
C’est une réponse en soi, et c’est rare : deux fois sur vingt-trois, et dans les deux cas la reconstruction a échoué ensuite. Un refus traduit souvent la crainte de voir apparaître une dette déjà connue plutôt qu’une dissimulation. La sortie consiste à proposer une recette conjointe, exécutée ensemble, où les constats sont partagés en direct.
Faut-il faire auditer par un tiers ou en interne ?
En interne si vous avez un profil technique senior qui n’a pas participé au projet — c’est la condition essentielle, car la proximité produit une indulgence involontaire. Un tiers coûte 2 500 à 5 000 EUR pour un périmètre de PME, soit moins que la retenue de garantie qu’il permet de justifier ou de libérer en connaissance de cause.