Communiquer des exigences radar a un fournisseur n’est pas une simple formalite d’achat. La qualite de la proposition depend beaucoup de la qualite du brief. Si l’acheteur demande seulement “un radar qui detecte les drones a 5 km”, le fournisseur doit deviner la cible, la geometrie, le fouillis, les interfaces, le flux d’alarme et les conditions d’acceptation.
Un meilleur brief donne assez de contexte pour proposer une architecture, expliquer les hypotheses, identifier les risques et dire ce qui peut etre prouve. Le but n’est pas d’allonger le document, mais de clarifier la question d’ingenierie.
Commencer par le resultat de mission
Commencez par ce que le systeme doit aider a accomplir. Un fournisseur repondra mieux a “detecter et suivre des drones basse altitude approchant un stade pendant des evenements, puis pointer EO/IR au centre de securite” qu’a “envoyer un prix pour un radar drone”.
Decrivez :
- l’actif ou la zone protegee ;
- l’evenement ou comportement important ;
- pourquoi la couche radar est necessaire ;
- le temps d’alerte requis ;
- qui utilisera l’information ;
- la decision que le systeme doit soutenir.
Cela aide a distinguer alerte precoce, surveillance perimetrique, securite temporaire, preuve, pointage camera ou fusion multi-capteurs.
Definir les cibles et scenarios
La performance radar depend de la cible. Un petit multirotor, un UAV fixe, un oiseau, une personne, un vehicule ou un petit bateau ne posent pas le meme probleme. Meme parmi les drones, taille, vitesse, altitude, materiaux, charge et comportement changent la performance.
Fournissez :
- classes de cibles ;
- plages typiques d’altitude et de vitesse ;
- routes d’approche attendues ;
- stationnement, traversier ou approche directe ;
- cible cooperative ou non ;
- hypothese RF emettante ou silencieuse ;
- objets genants mais non menacants.
Si vous ne savez pas, dites-le. Un bon fournisseur doit aider a raffiner les hypotheses.
Partager le contexte site
Le site change souvent la reponse plus que le modele radar. Fournissez plans, cartes, photos et notes.
Informations utiles :
- zones protegees et limites ;
- points de montage candidats ;
- options toit, mat, tour ou remorque ;
- hauteurs de batiments, relief, vegetation, eau, routes, grues, metal ;
- sources de fouillis connues ;
- alimentation et reseau ;
- terre et foudre ;
- acces maintenance et restrictions de securite ;
- horaires d’exploitation.
Si le site n’est pas final, partagez l’incertitude. Le fournisseur pourra proposer des options au lieu de figer une mauvaise hypothese.
Preciser les sorties et le flux operateur
Les exigences doivent dire ce que l’operateur doit recevoir, pas seulement ce que le capteur detecte.
Indiquez si le systeme doit fournir :
- position, hauteur, vitesse, cap et historique ;
- carte et zones d’alarme ;
- pointage camera EO/IR ;
- correlation RF ou Remote ID ;
- journaux et relecture ;
- formats d’export ;
- integration VMS, C2, PSIM ou logiciel client ;
- vues locales et distantes ;
- roles utilisateur et audit.
Cela evite un ecart frequent : le fournisseur livre un radar fonctionnel, mais le client attendait une image operationnelle integree.
Etre clair sur les contraintes
Les contraintes sont aussi importantes que les fonctions. Elles structurent le design et le prix.
Indiquez :
- budget ou fourchette si possible ;
- planning ;
- exigences export ou import ;
- preferences energie et reseau ;
- conditions environnementales ;
- limites d’installation ;
- exigences cybersecurite ;
- langues et documentation ;
- attentes de formation ;
- maintenance et support.
Si une contrainte est non negociable, dites-le. Si c’est une preference, dites-le aussi.
Separer obligatoire, souhaite et optionnel
Toutes les exigences n’ont pas le meme poids. Un bon brief separe :
- exigences obligatoires ;
- elements souhaites ;
- options a chiffrer ;
- hypotheses a confirmer ;
- questions ouvertes.
Cette structure facilite la comparaison des reponses et evite de noyer les points critiques dans un texte general.
Demander hypotheses et preuves
Une bonne reponse fournisseur ne doit pas seulement lister un modele. Elle doit expliquer les hypotheses de la recommandation.
Demandez :
- quelles hypotheses de cible sont utilisees ;
- quelles conditions site peuvent limiter la performance ;
- ce que signifient detection, suivi et alerte ;
- ce qui demande etude de site ou simulation ;
- ce qui sera prouve en FAT ;
- ce qui sera prouve en SAT ;
- quelles integrations sont incluses ou exclues ;
- quel support est inclus apres deploiement.
C’est ainsi que les promesses vagues deviennent des engagements d’ingenierie.
Inclure l’acceptation tot
L’acceptation ne doit pas etre inventee a la fin. Communiquez tot comment la reussite sera jugee.
Un modele pratique peut inclure :
- FAT pour materiel, logiciel, interfaces, journaux et documents ;
- SAT pour couverture, zones aveugles, cibles representatives, zones d’alarme, pointage camera, export et flux operateur ;
- preuves comme captures, logs, exports de pistes et fiches d’essai ;
- traitement des limites connues ;
- cloture des ecarts.
Si le fournisseur ne peut pas accepter ce principe, la discussion doit avoir lieu avant l’achat.
Modele simple de brief
Un brief utile peut tenir ainsi :
- Objectif du projet et site protege.
- Types de cibles et scenarios.
- Zones protegees, cartes et photos.
- Points de montage et contraintes.
- Sorties et integrations.
- Energie, reseau, cybersecurite et documents.
- Planning et logistique.
- Obligatoire, souhaite, optionnel.
- Attentes FAT et SAT.
- Questions auxquelles le fournisseur doit repondre.
Cela suffit pour lancer une discussion technique serieuse.
Mauvais briefs courants
Evitez :
- “Merci de proposer votre meilleur radar.”
- “Nous voulons 5 km de detection, envoyez le prix.”
- “Detecter tous les drones par tous les temps.”
- “Les details du site seront discutes apres achat.”
- “Le fournisseur garantit que tout fonctionne.”
Ces phrases forcent le fournisseur a deviner, et les devinettes deviennent couts, delais ou conflits d’acceptation.
Conclusion
La meilleure facon de communiquer des exigences radar est de decrire la mission, le site, les cibles, le flux operateur, les integrations et l’acceptation en termes d’ingenierie simples. Vous n’avez pas besoin de resoudre tout le design avant de parler aux fournisseurs, mais vous devez donner assez de contexte pour rendre les hypotheses visibles.
Des exigences claires rendent les propositions comparables, les performances testables et les malentendus moins probables lors de l’installation ou de l’acceptation.