Quand on audite le système d’information d’une mairie ou d’un syndicat intercommunal, on tombe encore régulièrement sur des modules métier qui appellent CAPICOM en arrière-plan. La bibliothèque de chiffrement développée par Microsoft servait à gérer les certificats numériques, signer des documents et chiffrer des flux depuis des applications Windows. Le problème : Microsoft a officiellement déprécié CAPICOM et stoppé toute mise à jour, laissant ces briques logicielles sans correctif de sécurité.
Détecter les applications qui utilisent encore CAPICOM dans un parc informatique public
Avant de parler migration, on doit savoir où CAPICOM se cache. La bibliothèque se présente sous la forme d’un fichier DLL (capicom.dll) enregistré sur les postes Windows. Dans une collectivité, elle est souvent embarquée dans des applicatifs métier anciens : parapheurs électroniques internes, modules de signature pour les marchés publics, ou outils de chiffrement de courriels entre services.
A découvrir également : Les meilleures adresses et bons plans pour vivre le business à Paris
Le réflexe le plus direct consiste à rechercher capicom.dll sur l’ensemble du parc via un script de déploiement ou un outil d’inventaire logiciel. On cible aussi les appels COM dans le registre Windows, parce que certaines applications chargent CAPICOM sans copier la DLL localement.
Les retours varient sur ce point : certaines DSI découvrent la dépendance uniquement au moment d’une migration de navigateur ou d’un changement de version de Windows, quand un module cesse brutalement de fonctionner. Sur le terrain, comme capicom expliqué par Collectivité Numérique le détaille, cette détection précoce évite des interruptions de service sur des procédures critiques comme la signature de bons de commande.
A voir aussi : Héritage et patrimoine : ce que la famille de Tony Scotti pourrait recevoir
CAPICOM et conformité eIDAS : pourquoi le statu quo pose un risque réglementaire
CAPICOM repose sur les API CryptoAPI historiques de Windows. Ces API ne prennent pas en charge les suites cryptographiques récentes exigées par les référentiels européens actuels. Les lignes directrices de l’ENISA et les profils de protection eIDAS 2.0 ont renforcé depuis 2023 les recommandations sur les algorithmes et les longueurs de clés pour les services de confiance.
CAPICOM n’est plus aligné avec les exigences cryptographiques européennes applicables aux signatures avancées et qualifiées. Pour une collectivité qui traite des marchés publics dématérialisés ou des actes administratifs signés électroniquement, maintenir une brique dépréciée fragilise la valeur probante des documents produits.
Le risque n’est pas théorique. Un certificat manipulé via CAPICOM peut reposer sur des algorithmes de hachage ou des longueurs de clés que les autorités de certification et les plateformes de vérification considèrent désormais comme insuffisants. En cas de litige, la conformité du processus de signature peut être contestée.
CryptoAPI Next Generation et .NET : choisir la bonne trajectoire de remplacement
Microsoft oriente les développeurs vers deux pistes principales pour remplacer CAPICOM. Le choix dépend du type d’application concernée et des compétences disponibles dans l’équipe technique.
CNG pour les applications natives Windows
CryptoAPI Next Generation (CNG) est le successeur direct de CryptoAPI. Il prend en charge les algorithmes modernes (AES avec clés longues, courbes elliptiques, suites TLS récentes). Pour une application native en C++ ou en Delphi qui appelait CAPICOM via COM, migrer vers CNG est le chemin le plus court.
La réécriture porte sur les appels de signature, de vérification de certificat et de chiffrement. Le reste du code applicatif reste généralement intact.
Namespace System.Security.Cryptography pour les applications .NET
Si l’application a été développée en VB.NET ou C#, le namespace System.Security.Cryptography couvre la totalité des fonctions qu’assurait CAPICOM :
- Signature et vérification de documents avec gestion complète du magasin de certificats Windows
- Chiffrement symétrique et asymétrique selon les standards actuels
- Horodatage et chaînage de certificats compatibles avec les exigences eIDAS
L’avantage de cette approche : les mises à jour de sécurité suivent le cycle de support de .NET, ce qui supprime le problème de la bibliothèque figée sans correctifs.
Planifier la migration CAPICOM dans une collectivité : les étapes critiques
On ne remplace pas CAPICOM en un sprint. La migration touche des processus métier sensibles, et chaque collectivité a un historique applicatif différent. Trois étapes structurent le projet.
- Cartographier les dépendances : identifier chaque application, chaque flux et chaque poste qui charge capicom.dll, puis documenter la fonction exacte utilisée (signature, chiffrement, vérification)
- Prioriser par criticité : les applications liées aux marchés publics ou à la signature d’actes passent en premier, celles qui ne font que du chiffrement interne peuvent attendre un second lot
- Tester en environnement isolé : valider que la nouvelle brique cryptographique produit des signatures acceptées par les plateformes de dématérialisation utilisées (profil de signature XAdES, PAdES selon les cas)
- Former les agents concernés : un changement de certificat ou de procédure de signature nécessite une communication claire auprès des utilisateurs finaux, même si le changement est transparent côté interface
Sur le terrain, la phase de cartographie prend souvent plus de temps que la réécriture elle-même, parce que les dépendances à CAPICOM ne sont pas toujours documentées dans les fiches applicatives.
Les collectivités qui repoussent cette migration s’exposent à une double contrainte : un risque de panne sèche lors d’une mise à jour Windows qui casse la compatibilité COM, et un défaut de conformité face aux exigences croissantes des référentiels de sécurité européens. Mieux vaut lancer l’inventaire maintenant, même si la réécriture complète s’étale sur plusieurs mois.