Faits établis
Informations confirmées par le client, par l’exploitant ou par une observation fiable du site. Elles peuvent servir de base à la rédaction.
Parcours fictif TRX-Drone — étape 4/16
ConOps PDRA : construire le dossier à partir d’une mission réelle
Le ConOps est souvent présenté comme une pièce documentaire parmi d’autres. Dans une démarche PDRA, il joue pourtant un rôle beaucoup plus important : il transforme une demande client parfois floue en opération compréhensible, discutable et vérifiable.
À partir du cas client fictif traité par TRX-Drone, cette page montre comment construire progressivement un ConOps utile : décrire la mission, identifier les contraintes, distinguer les faits des hypothèses, et préparer la vérification de l’adéquation avec un cadre PDRA.
Cette page est la deuxième étape du parcours. La première a posé le choix entre STS, PDRA, SORA, adaptation ou abandon. Ici, l’objectif est de rendre la mission suffisamment claire pour pouvoir décider.
Rappel de l’étape précédente
À l’étape précédente, TRX-Drone a engagé l’analyse PDRA. Cette page montre pourquoi le ConOps doit transformer la demande client en opération décrite, vérifiable et discutable.
Décrire l’opération avant de la justifier
La première fonction du ConOps est de décrire. TRX-Drone doit expliquer ce qui est prévu avant de chercher à démontrer que le PDRA est applicable. Cette étape oblige à clarifier la mission, le périmètre, les moyens, les limites et les responsabilités.
Dans le cas fictif, il ne suffit pas d’écrire “inspection technique par drone”. Il faut préciser l’objectif de l’inspection, le type d’ouvrage, la fréquence envisagée, les zones survolées ou évitées, les contraintes du donneur d’ordre, les horaires possibles, les conditions de préparation et les limites que l’exploitant accepte de se fixer.
Cette description est le premier test de crédibilité du dossier. Si l’opération reste floue dans le ConOps, elle le sera encore davantage dans la grille PDRA, le MANEX ou les échanges avec l’autorité.
Les informations à structurer dans le ConOps
Un ConOps PDRA doit être assez précis pour permettre la comparaison avec le scénario envisagé, sans devenir un document illisible. La logique est de regrouper les informations par fonction : comprendre la mission, situer l’environnement, identifier les risques et préparer la démonstration.
- Mission : finalité, livrable attendu, fréquence, périmètre et limites de la prestation.
- Site : environnement, accès, obstacles, voies de circulation, zones sensibles et contraintes locales.
- Aéronef : drone envisagé, équipements utiles, limitations, fonctions de sécurité et preuves disponibles.
- Organisation : télépilote, observateur éventuel, responsable d’exploitation, coordination client.
- Volumes : zone d’exploitation, marges, zones à éviter, contingence et interruption de mission.
- Tiers : personnes non impliquées, coactivité, public éventuel, usagers ou intervenants du site.
- Procédures : préparation, vol nominal, dégradation, urgence, arrêt et retour d’expérience.
- Hypothèses : points établis, points supposés, points à confirmer avant toute demande complète.
Ce classement évite de transformer le ConOps en récit désordonné. Il permet aussi de repérer les informations manquantes avant d’aller plus loin.
Distinguer les faits, les hypothèses et les incertitudes
Dans le cas client traité par TRX-Drone, certaines informations sont établies : le besoin client, le type général de mission, la localisation de l’infrastructure et la volonté de répéter les inspections. D’autres éléments restent à vérifier : conditions exactes de présence de tiers, contraintes locales, drone finalement utilisé, plages horaires possibles ou modalités d’interruption de mission.
Hypothèses raisonnables
Informations plausibles, mais encore dépendantes d’une confirmation. Elles doivent être présentées comme telles et non comme des certitudes.
Incertitudes critiques
Points pouvant modifier la trajectoire réglementaire. Ils doivent être traités avant de conclure que le PDRA est applicable.
Cette distinction est importante. Un dossier qui présente une hypothèse comme une certitude peut devenir fragile dès les premiers échanges avec l’autorité.
Transformer la mission en logique documentaire
Une fois la mission décrite, TRX-Drone doit transformer cette description en éléments exploitables pour le dossier. Le ConOps n’est pas isolé. Il prépare la grille PDRA, les procédures, le MANEX, les annexes techniques et la demande déposée via METEOR.
Par exemple, si le ConOps annonce une surveillance de la zone, le dossier devra expliquer qui réalise cette surveillance, depuis où, selon quelle procédure, avec quelle capacité d’action et dans quelles limites. Si le ConOps prévoit une interruption de mission, cette interruption devra être décrite dans les procédures et reliée aux moyens réellement disponibles.
C’est ici que l’on voit la différence entre un ConOps utile et un texte décoratif. Un bon ConOps prépare les preuves. Un mauvais ConOps empile des intentions.
Ce qu’il faut éviter dans un ConOps PDRA
- Décrire une mission trop générale qui pourrait s’appliquer à n’importe quel site.
- Utiliser des phrases rassurantes sans préciser les moyens concrets.
- Omettre les situations dégradées ou les conditions d’arrêt.
- Promettre des dispositifs non disponibles ou non maîtrisés.
- Masquer les incertitudes pour donner l’impression que le dossier est prêt.
- Commencer par la conclusion “le PDRA s’applique” avant d’avoir démontré l’adéquation.
Le ConOps doit rester sobre, mais il doit être honnête. Sa valeur vient de sa capacité à faire apparaître clairement ce qui est maîtrisé et ce qui ne l’est pas encore.
Dernière mise à jour : 17 mai 2026