Dans la quasi-totalité des marchés informatiques passés par les collectivités et les établissements publics, la sécurité figure en bonne place. Elle apparaît dans le préambule du CCTP, dans les critères de jugement des offres, parfois dans un mémoire technique de plusieurs dizaines de pages où le candidat détaille ses certifications et sa politique interne. Puis le marché est notifié, l'intégration se déroule, la solution est admise, et personne ne vérifie jamais si les engagements pris valaient autre chose que le papier sur lequel ils étaient imprimés. La sécurité était une intention. Elle n'était pas une obligation et c'est tout le problème.

Cet écart n'est pas anecdotique. Il concentre, à lui seul, l'essentiel du risque numérique que portent aujourd'hui les acheteurs publics. Car l'entité adjudicatrice demeure responsable de son système d'information : lorsque la messagerie est chiffrée par un rançongiciel entré par un accès de télémaintenance mal cloisonné, ce n'est pas l'intégrateur qui affronte les administrés, la CNIL et la presse locale. Mais les élus locaux et les personnels de la collectivité.

La seule façon de rééquilibrer cette asymétrie consiste à transformer la déclaration de sécurité en prestation vérifiable, chiffrée, exigible et sanctionnable. Autrement dit : à écrire la clause.

Ce que l'on achète réellement quand on achète un audit

La première difficulté est lexicale. « Audit de sécurité » recouvre des prestations dont ni le coût, ni la durée, ni la valeur probante ne sont comparables. Le référentiel PASSI de l'ANSSI en distingue cinq :

  • l'audit d'architecture, qui examine la conception et le cloisonnement ;
  • l'audit de configuration, qui vérifie le paramétrage réel des équipements et des systèmes ;
  • l'audit de code source, qui inspecte les développements spécifiques ;
  • le test d'intrusion, qui cherche à exploiter concrètement les failles depuis la position d'un attaquant ;
  • et l'audit organisationnel et physique, qui interroge les procédures et les accès.

Un acheteur qui écrit « le titulaire fera réaliser un audit de sécurité » achète, en pratique, le moins-disant de cette liste, le plus souvent un balayage automatisé produisant un rapport d'outil sans interprétation. La clause doit donc nommer les prestations attendues, et les articuler au projet : audit de configuration et test d'intrusion interne pour un déploiement d'équipements réseau, audit de code et test d'intrusion applicatif authentifié pour une intégration logicielle métier, audit d'architecture pour toute refonte d'interconnexion. Elle doit également exiger que ces travaux soient conduits par un prestataire qualifié PASSI, ou à tout le moins par un tiers dont l'indépendance à l'égard du titulaire est établie. Faire auditer l'intégrateur par l'intégrateur n'est pas un contrôle, c'est une formalité.

Le moment détermine la valeur

Une clause d'audit placée au mauvais endroit du calendrier ne produit aucun effet. Si l'audit intervient après l'admission et le paiement du solde, l'acheteur a perdu tout levier : il ne lui reste que la garantie, dont l'invocation est lente et contentieuse. La position juste consiste à conditionner la vérification de service régulier - et donc l'admission - à la production d'un rapport d'audit et à la remédiation des vulnérabilités critiques et majeures qu'il révèle. La sécurité cesse alors d'être un livrable parmi d'autres pour devenir une condition d'exécution.

Ce premier rendez-vous ne suffit pas. Un système d'information n'est sûr qu'à l'instant de sa mesure. La clause doit donc prévoir une périodicité (annuelle pour les composants exposés, biennale pour les autres) et déclencher un contrôle après tout changement structurant : montée de version majeure, ouverture d'un nouveau flux, adjonction d'un site, changement de sous-traitant ou d'hébergeur. Ce dernier point mérite une attention particulière : le droit d'audit doit être stipulé opposable à toute la chaîne de sous-traitance, sous peine de s'arrêter à la première interface externalisée, c'est-à-dire précisément là où le risque se concentre.

L'angle mort des réseaux LAN et WAN

Les projets applicatifs bénéficient d'une vigilance croissante ; les infrastructures réseau, beaucoup moins. C'est une erreur d'appréciation. Un commutateur de cœur, un pare-feu périmétrique, un concentrateur SD-WAN ou un routeur d'interconnexion sont des équipements dont la compromission ne dégrade pas un service : elle ouvre l'ensemble du système d'information. Ils sont livrés avec des comptes d'administration par défaut, des interfaces de gestion parfois joignables depuis le réseau bureautique, des micrologiciels dont le cycle de mise à jour n'est pas contractualisé, et des accès de télémaintenance ouverts au profit du fournisseur sans traçabilité ni cloisonnement.

Pour ces marchés, la clause d'audit doit porter sur des objets précis : la configuration effective des équipements livrés au regard des guides de durcissement applicables, la réalité de la segmentation entre les domaines bureautique, métier, industriel et téléphonie, la gestion des comptes à privilèges et l'authentification forte des administrateurs, les modalités techniques de l'accès distant du titulaire, l'exposition des interfaces d'administration, enfin l'engagement de maintien en condition de sécurité sur toute la durée du marché avec un délai de qualification et de déploiement des correctifs de sécurité. Un test d'intrusion interne, conduit depuis une prise réseau ordinaire, en dit davantage sur la robustesse réelle d'un déploiement que l'ensemble du mémoire technique qui l'a précédé.

Trois précautions rédactionnelles

Une clause d'audit doit d'abord être licite. Un test d'intrusion sans autorisation écrite constitue une atteinte à un système de traitement automatisé de données ; le marché doit donc porter le mandat, délimiter le périmètre technique, fixer la fenêtre d'intervention et désigner les points de contact des deux parties. Cette autorisation protège autant l'auditeur que l'acheteur.

Elle doit ensuite prévoir le traitement des constats, faute de quoi le rapport rejoindra une armoire. Le mécanisme utile associe une échelle de criticité, des délais de remédiation différenciés (quelques jours pour une vulnérabilité critique, quelques semaines pour une vulnérabilité majeure), un contre-audit de vérification à la charge du titulaire lorsque les défauts lui sont imputables, et un régime de pénalités adossé à la retenue de garantie. La résiliation aux torts doit rester disponible pour les manquements répétés.

Elle doit enfin être financée. Un audit qui n'apparaît dans aucun poste du bordereau de prix ne sera pas réalisé, ou le sera au rabais. L'ordre de grandeur est modeste (un à trois pour cent du montant du projet) et il est souvent judicieux de le sortir du marché principal pour le confier à un accord-cadre distinct, ce qui garantit l'indépendance de l'auditeur tout en mutualisant la dépense sur plusieurs opérations.

Une exigence qui devient une obligation

Ce raisonnement, longtemps affaire de bonne pratique, change de nature avec la transposition de la directive NIS2, qui étend le périmètre des entités soumises à des obligations de cybersécurité à un grand nombre de collectivités et d'opérateurs publics, et qui place explicitement la sécurité de la chaîne d'approvisionnement au rang des mesures attendues. La maîtrise contractuelle de ses fournisseurs informatiques ne relève donc plus du confort de l'acheteur avisé : elle devient un élément de conformité.

Il n'y a là aucune défiance envers les prestataires. Les intégrateurs sérieux accueillent favorablement des exigences claires, parce qu'elles assainissent la concurrence et les protègent des offres construites sur l'économie de la sécurité.

La clause d'audit ne complique pas le marché : elle le rend enfin vérifiable. Et permet ensuite d'éviter d'importants dommages en cas de cyberattaque comme on a pu le voir en France depuis plusieurs mois.


Strategicity accompagne les collectivités et établissements publics dans la définition de leurs exigences de sécurité des systèmes d'information, la rédaction des pièces contractuelles et le copilotage des vérifications tout au long de l'exécution.