PREUVE / Feuillet de consultation

Pentest en production ou préproduction : arbitrer les contraintes

Mis à jour le 1er octobre 2026

Choisir une représentativité documentée

La production reflète l’usage réel, mais elle peut contenir des données clients et des fonctions dont l’impact est difficile à maîtriser. La préproduction permet souvent de préparer des jeux fictifs et de limiter les effets de bord. Elle peut toutefois différer de la production. Le choix doit être arbitré avec le cabinet, l’exploitation et l’acheteur. Aucun environnement n’est automatiquement le bon pour toutes les applications ou toutes les clauses de vente.

Commencez par lister les différences : version, configuration, authentification, stockage, réseau, cache, services tiers et droits. Une préproduction simplifiée ne démontre pas les mêmes propriétés qu’une production plus complexe. Le rapport doit conserver cette information. Si le grand compte exige une preuve sur la production, demandez ce qu’il entend par cette exigence et quelles limites d’intervention il accepte.

Préparer les données et accès

En préproduction, créez des données fictives qui reproduisent les parcours et les relations utiles au test. Un environnement vide peut empêcher l’examen des recherches, exports ou délégations. Évitez une copie brute de la base clients. Si des données personnelles sont nécessaires, leur usage et leurs protections doivent être examinés selon le cadre réel du traitement. Le principe pratique reste de réduire les données et les risques de divulgation.

En production, utilisez des comptes dédiés et des objets de test reconnaissables. Définissez les frontières avec les utilisateurs réels. Le cabinet doit savoir comment réagir si une information inattendue apparaît. Les rôles fournis doivent correspondre aux scénarios autorisés, avec une durée bornée et un responsable de révocation. La mise à disposition d’un compte ne doit pas élargir silencieusement le mandat à toute l’infrastructure.

Borner les effets de bord

Certaines opérations déclenchent des notifications, des paiements, des exports ou des traitements différés. Identifiez-les avant mission. Convenez des fonctions simulées, désactivées ou exclues et de l’effet de ces choix sur la conclusion. Les tests de charge et de disponibilité doivent être discutés explicitement. Un pentest applicatif ne vaut pas autorisation implicite de provoquer une interruption de service.

Prévoyez les seuils d’arrêt et les contacts disponibles. L’exploitation doit reconnaître les opérations du cabinet dans les journaux et pouvoir interrompre un scénario. Les données créées pendant l’audit doivent être nettoyées, y compris celles utilisées par des tâches planifiées. La procédure de retour à un état nominal mérite un responsable identifié, surtout lorsque le système sert simultanément des clients.

Stabiliser la version pendant mission

Un déploiement pendant les tests peut modifier le comportement et rendre une preuve difficile à interpréter. Convenez de la politique de changement : gel sur certaines fonctions, information préalable ou reprise ciblée après livraison. Le rapport doit identifier la version ou le contexte examiné. Si un correctif urgent intervient, conservez sa date et sa relation avec les constats plutôt que de fusionner tous les résultats sous un seul état.

Les paramètres de sécurité doivent être représentatifs. Une authentification différente ou une restriction réseau temporaire peut changer la surface observée. Ces mesures peuvent être utiles pour maîtriser l’audit, mais leur effet sur la portée doit être expliqué. Le client peut accepter une limite documentée ; il ne peut pas évaluer une différence qui reste absente de la synthèse.

Présenter une conclusion limitée au test

Demandez au cabinet de distinguer les observations vérifiées et les hypothèses de transposition entre environnements. Un retest en préproduction confirme la correction dans ce contexte ; le déploiement en production doit être suivi séparément. Selon le risque et la clause client, une vérification complémentaire peut être nécessaire. Le devis initial doit prévoir comment ce besoin est décidé et chiffré.

Préparez une note de correspondance entre les environnements pour le dossier de vente. Elle peut indiquer les éléments identiques, les différences et les vérifications supplémentaires réalisées. N’inventez pas une équivalence totale pour raccourcir la revue achat. La direction commerciale communique la preuve disponible avec ses réserves, tandis que le CTO conserve les détails permettant de suivre les changements et les corrections.