Checklist RFP pour radar counter-UAS

Une demande de propositions pour un radar counter-UAS décide de bien plus que le prix d’achat : elle détermine ce que l’acheteur pourra exiger du fournisseur par la suite. Un RFP vague produit des propositions qui ont toutes l’air conformes tout en signifiant des choses différentes ; un RFP précis oblige chaque fournisseur à répondre aux mêmes questions testables.

Cette liste de contrôle s’adresse aux équipes d’achat, aux intégrateurs et aux utilisateurs finaux qui préparent un appel d’offres pour un radar de détection de drones. Elle suit l’ordre d’une évaluation réelle : définir la mission, spécifier des performances testables, verrouiller l’intégration et la réception, puis structurer les conditions commerciales et de conformité. Pour le détail de chaque champ de spécification au niveau de la fiche technique, voir la liste de contrôle pour fiche technique radar counter-UAS associée.

1. Définir d’abord l’exigence opérationnelle

L’échec le plus courant d’un RFP consiste à copier une brochure fournisseur dans la section des exigences. Avant toute spécification, documentez ce que le radar doit réellement faire :

• Définition de la menace : quelles classes de drones comptent — quadricoptères grand public, drones FPV, drones à voilure fixe, gros multirotors — et quelle est la plus petite surface équivalente radar que le système doit traiter.
• Actif protégé et site : installation fixe, événement temporaire, couloir frontalier, unité mobile ; résultats de l’étude de site, y compris le terrain, les sources de clutter et les points de montage disponibles.
• Exigence de couverture : secteurs ou 360 degrés complets, portée d’engagement minimale et maximale, bande d’altitude d’intérêt.
• Chaîne de réaction : qui reçoit l’alarme, ce qu’il en fait, et si le radar doit pointer des caméras EO/IR, alimenter une plateforme de commandement ou déclencher une réponse automatisée.
• Concept d’emploi : fonctionnement 24/7 sans surveillance, déploiement événementiel ou postes de veille opérateur.

Chaque exigence technique qui suit doit pouvoir être rattachée à l’une de ces déclarations. Si une spécification ne se rattache à aucun besoin opérationnel, il s’agit probablement de langage de brochure.

2. Exigences de spécification technique

Rédigez les exigences de performance de telle sorte que la conformité puisse être démontrée, et pas seulement affirmée. Chaque point ci-dessous doit figurer dans le RFP avec un format de réponse imposé :

• Portée de détection et de suivi contre une SER de cible déclarée (par exemple 0,01 m²), avec probabilité de détection et conditions de fausse alarme. Exigez que les fournisseurs séparent la première détection, la piste stable et la distance d’alerte exploitable.
• Couverture : champ de regard en azimut, couverture en élévation, et nombre d’unités nécessaires pour couvrir 360 degrés.
• Fréquence de mise à jour ou temps de revisite pour la couverture déclarée, ainsi que la capacité de pistes avec plusieurs cibles simultanées.
• Précision : précision en distance, en azimut et en élévation suffisante pour le pointage ou le transfert prévu.
• Classification : méthode de discrimination oiseau/drone et comportement attendu dans l’environnement de clutter réel de l’acheteur.
• Environnement : pluie, vent, température et indices de protection adaptés au site, et non à une condition de laboratoire générique.

Évitez de spécifier une seule portée maximale sans hypothèse de cible : cela invite chaque fournisseur à répondre à une question différente.

3. Sorties et intégration

Beaucoup de projets counter-UAS échouent à l’intégration, pas à la détection. Le RFP doit exiger que les fournisseurs documentent :

• le format de sortie des pistes, le schéma de messages et l’intervalle de mise à jour ;
• les interfaces réseau, les protocoles et la synchronisation temporelle ;
• la prise en charge du pointage EO/IR, avec latence et précision de pointage démontrées ;
• les options d’intégration pour la détection RF, Remote ID et les plateformes C2, VMS ou PSIM ;
• la disponibilité d’une API ou d’un SDK, des exemples de messages et la répartition des responsabilités d’intégration ;
• les contrôles de cybersécurité, les rôles utilisateurs, la journalisation et le comportement en cas de perte réseau.

Exigez des exemples de documentation d’interface dans la proposition, et non après l’attribution.

4. Site, installation et essais de réception

Le RFP doit faire de la réception un processus contractuel fondé sur des preuves, et non une formalité. Une étude de site menée avant l’émission de l’appel d’offres donne à tous les fournisseurs la même image de l’installation et rend leurs devis comparables.

Incluez :

• Exigences d’installation : montage, alimentation et consommation, mise à la terre, limites de câbles, exigences réseau et génie civil éventuel à la charge de l’acheteur.
• Essai de réception en usine (FAT) : la liste de contrôle que le fournisseur exécutera avant expédition, y compris les enregistrements de configuration et de version.
• Essai de réception sur site (SAT) : hypothèses de cible d’essai, profils de vol, critères de réussite ou d’échec pour la détection, le suivi, l’alerte et le pointage, ainsi que le processus de gestion des écarts et de reprise.
• Livrables de preuve : exemples de journaux, pistes exportées, captures d’écran et enregistrements d’étalonnage dans des formats que l’acheteur peut archiver.

Si une exigence ne peut pas être testée en FAT ou en SAT, rendez-la testable ou supprimez-la.

5. Conformité et export

Le radar counter-UAS est une catégorie de produit contrôlée dans de nombreuses juridictions, et les systèmes de plus longue portée peuvent relever des règles d’exportation des biens à double usage. Le RFP doit demander aux fournisseurs de déclarer :

• la classification export applicable et la responsabilité des licences ;
• le délai de livraison attendu, y compris le délai d’obtention des licences ;
• la documentation d’utilisateur final que l’acheteur doit fournir ;
• toute variante régionale, coordination de fréquences ou exigence de licence radio dans le pays de déploiement.

Les acheteurs novices dans ce domaine devraient consulter la présentation de la conformité export des radars dual-use avant d’émettre l’appel d’offres, afin que les questions de conformité figurent dans le RFP au lieu de surgir après la signature du contrat.

6. Évaluation des fournisseurs et conditions commerciales

Structurez les réponses pour que les offres puissent être comparées ligne à ligne :

• Matrice de conformité : chaque exigence répondue en conforme / partiellement conforme / non conforme, avec explication écrite et preuve.
• Références : systèmes déployés dans la même configuration, avec des utilisateurs finaux joignables si possible.
• Présence de l’entreprise et de l’assistance : support local, diagnostics à distance, disponibilité des pièces détachées et engagements de délai de réponse.
• Conditions commerciales : prix ventilé entre matériel, logiciel, intégration, formation, pièces détachées et assistance récurrente ; durée de garantie et exclusions ; jalons de paiement liés au FAT, à la livraison et au SAT.
• Coûts de cycle de vie : politique de mise à jour logicielle, calendrier d’étalonnage et maintenance prévue — le coût total de cycle de vie d’un radar dépasse régulièrement son prix d’achat sur sa durée de service.

Utilisez des critères d’évaluation pondérés, publiés dans le RFP lui-même — par exemple 40 % de conformité technique, 20 % de preuves de réception, 20 % de cycle de vie et assistance, 20 % de prix — pour que les fournisseurs optimisent ce qui compte vraiment.

7. Documentation, formation et support

Exigez avec la proposition :

• le périmètre, la durée et la langue de la formation des opérateurs et des maintenanciers ;
• l’ensemble documentaire : manuel utilisateur, guide d’installation, document de contrôle d’interface, calendrier de maintenance ;
• la langue de la documentation et le contrôle des révisions ;
• la méthode d’assistance à distance et les options d’assistance sur site ;
• le plan d’inspection et de maintenance recommandé.

Erreurs courantes de RFP

Surveillez ces schémas lors de la rédaction ou de la revue de l’appel d’offres :

• Copier la fiche technique d’un fournisseur dans les exigences, ce qui exclut de fait la concurrence et masque des affirmations non testées.
• Spécifier une portée maximale sans SER de cible, altitude, probabilité ou conditions de fausse alarme.
• Omettre la fréquence de mise à jour, la géométrie de couverture ou la capacité de pistes.
• Laisser les protocoles d’intégration « à déterminer après attribution ».
• Ne définir aucun critère de réussite ou d’échec au SAT, de sorte que la réception devient une négociation.
• Ignorer les licences d’exportation jusqu’après la signature du contrat.
• Comparer les offres sur le seul prix d’achat alors que les politiques d’assistance et de mise à jour diffèrent.

Conclusion

Un bon RFP de radar counter-UAS se lit comme un plan d’essai rattaché à un cadre commercial : chaque exigence reliée à un besoin opérationnel, chaque affirmation de performance testable en FAT ou en SAT, chaque interface d’intégration documentée, et chaque fournisseur répondant aux mêmes questions dans le même format.

Construit ainsi, l’appel d’offres rend l’évaluation directe. Les matrices de conformité séparent les preuves du marketing, les critères de réception protègent l’acheteur après l’attribution, et le choix final reflète l’adéquation opérationnelle. Les fournisseurs de systèmes réellement déployés — y compris la gamme CR de Cyrentis de radars counter-UAS à impulsions et FMCW couvrant la courte à la longue portée — accueillent en général favorablement ce style de RFP, car les exigences testables sont le terrain où la performance vérifiée l’emporte sur les chiffres d’annonce.