À propos du blog

Nous tenons ce blog parce que l'ingénierie des logiciels de défense est mal documentée publiquement. La plupart de ce qui est publié traite le domaine soit comme un exercice de passation de marchés — fournisseurs, programmes, valeurs des contrats — soit s'arrête à la couche marketing des buzzwords comme « AI-enabled » et « next-generation ». Aucun n'est utile à un ingénieur qui doit réellement construire un tableau de bord C2, intégrer une liaison de données conforme STANAG, ou concevoir un contrôle d'accès basé sur les rôles pour un déploiement de coalition.

Notre objectif est de combler ce vide avec des articles techniques écrits par les personnes qui font le travail. Chaque article doit être suffisamment spécifique pour qu'un ingénieur rencontrant le problème pour la première fois puisse l'utiliser comme point de départ — ce que dit la norme, pourquoi les compromis existent, où trouver les références. Nous n'écrivons pas d'opinions sur la politique de défense, ni de comparaisons de fournisseurs que nous ne pouvons étayer, ni de hype sur les technologies émergentes. Le public visé est constitué d'ingénieurs, d'acheteurs techniques et des analystes qui les conseillent.

Les articles sont rédigés par l'équipe d'ingénierie de Corvus Intelligence — les mêmes ingénieurs qui conçoivent, construisent et exploitent les produits logiciels de défense que nous livrons. La paternité est collective plutôt qu'individuelle : chaque article passe une relecture technique interne par au moins un ingénieur ayant une expérience opérationnelle directe dans le domaine concerné (logiciels C2, fusion de données, intégration ATAK/WinTAK, interopérabilité OTAN, chaîne d'approvisionnement logicielle sécurisée) avant publication.

Pour l'équipe de l'entreprise, la direction et notre travail plus large, voir la page « À propos de l'entreprise ».

Les articles s'appuient sur trois principaux types de matériel source :

• Normes OTAN et alliées — STANAG publiés, ADatP, spécifications FMN Spiral, et les parties publiques des normes alliées d'échange de données.
• Documentation publique de fournisseurs et de projets — documentation officielle des outils avec lesquels nous travaillons quotidiennement (Cesium, Mapbox, courtiers MQTT, TAK Server, bibliothèques open-source CoT, middleware de bus de messages, etc.).
• Expérience opérationnelle d'ingénierie — patterns et compromis issus de la construction, du déploiement et de l'exploitation de logiciels de défense en environnement de production.

Nous excluons délibérément plusieurs catégories de contenu :

• Tout ce qui est couvert par un NDA client — y compris les topologies de systèmes, les noms d'opérateurs, les lieux de déploiement et les configurations spécifiques.
• Tout contenu classifié, peu importe à quel point il est apparu ailleurs en ligne.
• Récompenses, résultats de concours ou reconnaissance lors de hackathons — par décision éditoriale, le blog se concentre sur la substance technique plutôt que sur la reconnaissance.
• Affirmations spéculatives sur des produits que nous n'avons pas construits ou des technologies que nous n'avons pas utilisées.

Si un article s'appuie sur un travail non publié ou une observation propriétaire, nous le disons explicitement et le décrivons en termes suffisamment généraux pour ne compromettre aucun client.

Lorsqu'un article formule une affirmation factuelle spécifique — exigence STANAG, vulnérabilité publiée, comportement documenté d'un fournisseur — nous citons la source publique. Les références typiques comprennent :

• STANAG et ADatP publics de l'OTAN (les parties non classifiées publiées via le Bureau de standardisation de l'OTAN).
• RFC de l'IETF et autres documents de normes Internet.
• Rapports publics de renseignement sur les cybermenaces de CISA, ENISA, CERT nationaux et fournisseurs réputés.
• Documentation de projets open source, notes de version et code source.
• Publications académiques et industrielles librement accessibles en ligne.

Si vous trouvez une citation incorrecte, obsolète ou qui pointe vers une URL déplacée, nous voulons le savoir.

Le blog est organisé autour de six guides piliers, chacun associé à une série de mise en œuvre en quatre parties. Ensemble, ils couvrent l'arc complet, du cadrage architectural à la mise en œuvre d'ingénierie, jusqu'au contexte de passation des marchés :

• Systèmes de commandement et contrôle (C2) — ingénierie de l'image opérationnelle, messagerie tactique, contrôle d'accès basé sur les rôles pour les données classifiées.
• Fusion de données de défense — corrélation multi-sources au niveau JDL, gestion du cycle de vie, traitement de la classification multi-INT.
• Interopérabilité OTAN — sélection STANAG, liaisons de données tactiques (Link 16, CoT, MIP4-IES), préparation FMN Spiral, accréditation CWIX.
• IA dans la défense — la boucle capteur-tireur F2T2EA, IA en périphérie, aide à la décision, limites HITL.
• Cybersécurité de défense — modélisation des menaces, pipelines CTI (STIX/TAXII), SIEM/SOAR pour enclaves classifiées, défense ICS/OT, zero-trust.
• Marché et achats de défense — mécanique des RFP, conformité équivalente DCAA, exécution EVM, croissance du soutien.

Corrections, indications de sources et suggestions de sujets sont les bienvenues à contact@corvusintell.com. Pour les demandes commerciales concernant les produits discutés dans ces articles, utilisez la même adresse. Nous ne gérons pas de programme de contenu sponsorisé et nous n'acceptons pas d'articles invités.