Développement, acquisition, inventaire et licences

Bonne lecture et bon apprentissage ! Junior TSAFACK – 09/10/2026 Temps de lecture estimé : 12 minutes

Avant même qu’un actif existe dans l’organisation, une décision structurante doit être prise : le construire sur mesure, ou l’acheter sur étagère ? Cette décision engage l’organisation pour des années — et elle doit intégrer la sécurité dès le départ, pas comme une réflexion après coup.

Construire ou acheter ?

Facteur	Pencher vers « construire »	Pencher vers « acheter »
Exigences de sécurité	Besoins hautement spécialisés, que le commerce ne couvre pas ou à un coût prohibitif (institutions financières, entités gouvernementales).	Besoins standards, bien couverts par l’offre du marché.
Conformité réglementaire	Exigences sectorielles strictes (RGPD, PCI DSS) que les produits sur étagère ne couvrent pas nativement.	Le produit du marché est déjà certifié conforme.
Expertise interne	L’organisation dispose de l’expertise pour concevoir et maintenir la sécurité du système dans la durée.	L’organisation manque de personnel ou de connaissances pour maintenir un système sur mesure en sécurité.
Coût total de possession	Coût initial plus élevé, économies potentielles à long terme (moins de dépendance aux fournisseurs).	Coûts récurrents de licence, mais déploiement plus rapide.
Délai de déploiement	Plus long.	Nettement plus rapide — sauf si une personnalisation poussée est nécessaire.
Fiabilité du fournisseur	N/A	Réputation, solidité des pratiques de sécurité, qualité du support continu à évaluer.
Évolutivité	Contrôle total sur l’adaptabilité future.	Dépend de la capacité du fournisseur à suivre la croissance de l’organisation.

Le cycle de développement matériel sécurisé

Développer un système matériel sécurisé suit un processus en plusieurs étapes, chacune exigeant une prise en compte explicite de la sécurité :

Analyse des besoins — définir les exigences fonctionnelles et de sécurité, identifier les menaces et les vecteurs d’attaque potentiels dès cette étape.
Conception — intégrer la sécurité dès l’architecture (moindre privilège, modélisation des menaces pour simuler les attaques possibles).
Mise en œuvre — construction effective, suivant les meilleures pratiques de fabrication sécurisée et de codage sécurisé pour tout micrologiciel embarqué.
Vérification et tests — tests fonctionnels et tests spécifiques à la sécurité, dont les tests d’intrusion.
Production sécurisée — contrôler l’accès physique à la chaîne de fabrication pour empêcher la falsification ou l’insertion de composants malveillants.
Déploiement — installation sécurisée, mise en place des clés cryptographiques, formation des utilisateurs finaux aux fonctions de sécurité.
Maintenance et mises à jour — mise à jour régulière du microprogramme, audits de sécurité périodiques.
Gestion de la fin de vie — élimination et mise hors service sécurisées, pour éviter toute fuite de données depuis un appareil mis au rebut.

DevSecOps : la sécurité intégrée au développement logiciel

DevOps unifie le développement logiciel (Dev) et son exploitation (Ops) : automatisation, intégration continue (CI) et livraison continue (CD) permettent un déploiement fréquent, fiable et reproductible, en étroite adéquation avec les besoins métier.

DevSecOps étend DevOps en intégrant la sécurité comme un élément central tout au long du pipeline, plutôt que comme une phase finale distincte. Le principe directeur est le décalage vers la gauche (shift left) : intégrer les considérations de sécurité et les tests dès le début du développement, pour détecter et corriger les problèmes pendant le développement — à un coût bien moindre que s’ils étaient découverts en production.

Concrètement, DevSecOps combine :

des tests manuels et des revues par les pairs ;
des tests automatisés de sécurité à chaque étape, du codage au déploiement ;
des boucles de rétroaction rapides : dès qu’un problème de sécurité est détecté, il est immédiatement communiqué à l’équipe de développement, sans attendre une phase ultérieure.

En rendant chacun responsable de la sécurité — développeurs, spécialistes sécurité, personnel d’exploitation — DevSecOps réduit le coût et l’effort nécessaires à la conformité et à la correction des vulnérabilités, sans sacrifier la rapidité propre à DevOps.

Inventaire et licences logicielles

Une bonne gestion des ressources exige que tous les actifs logiciels — développés en interne ou acquis auprès de tiers — soient comptabilisés et documentés avec précision : versions, correctifs, dépendances. Une gestion efficace des dépendances permet d’évaluer l’impact d’un changement avant de le déployer, et de garantir la compatibilité entre composants.

Logiciel à code source fermé (propriétaire)

Le code source n’est pas public. L’utilisateur accepte un accord de licence qui définit les conditions d’usage — il achète en général le droit d’utiliser le logiciel pour une période donnée, pas le logiciel lui-même. Les éditeurs offrent généralement un support client, des mises à jour et des correctifs qui maintiennent le logiciel sécurisé et compatible.

Logiciel open source

Le code source est accessible, consultable, modifiable et redistribuable — mais pas nécessairement libre d’usage sans condition : son utilisation, sa modification et son partage peuvent rester soumis à des restrictions.

Les licences permissives (MIT, Apache) autorisent même l’intégration dans des projets propriétaires.
Les licences copyleft (GNU GPL) exigent que tout travail dérivé soit distribué sous la même licence open source.
La plupart des licences open source exigent de citer les auteurs originaux et de conserver les avis de copyright.
La loi de Linus (« avec suffisamment d’yeux, tous les bogues sont superficiels ») soutient que la visibilité du code favorise une correction plus rapide des failles — un argument contesté par ceux qui estiment que le code fermé, inaccessible aux attaquants, offre une sécurité par obscurité plus forte. Aucun camp n’a définitivement raison : cela dépend du contexte.
La plupart des logiciels open source ne garantissent aucun support, mise à jour ou maintenance formelle — une question à se poser explicitement avant de l’adopter en production.

Qu’il soit open source ou propriétaire, tout logiciel doit être suivi et inventorié pour que l’organisation sache si elle respecte réellement ses licences, et pour éviter de racheter inutilement ce qu’elle possède déjà.

Synthèse

La décision « construire ou acheter » doit intégrer les exigences de sécurité, la conformité, l’expertise interne et le coût total de possession — pas seulement le prix d’achat initial.
Le cycle de développement matériel sécurisé intègre la sécurité à chaque étape, de l’analyse des besoins à la fin de vie.
DevSecOps déplace la sécurité vers l’amont du pipeline de développement (shift left) plutôt que de la traiter comme une étape finale.
L’inventaire des licences logicielles — open source comme propriétaires — est une composante à part entière de la gestion des actifs, pas une simple formalité juridique.

Prochain chapitre

Mise en œuvre, maintenance et fin de vie

Junior TSAFACK – 09/10/2026