Pavois : l’outil open source français qui vérifie ce que votre serveur Linux applique vraiment

Sécuriser correctement un serveur Linux produit généralement une jolie collection de fichiers de configuration. On ajuste /etc/ssh/sshd_config, on modifie quelques valeurs dans sysctl.conf, on active auditd, on désactive deux ou trois services inutiles et, après quelques heures de bataille avec YAML, Ansible annonce fièrement que tout est au vert.

À ce moment-là, la tentation naturelle consiste à considérer le serveur comme correctement durci et à passer au suivant.

Le problème, c’est qu’un fichier de configuration n’est pas forcément la vérité.

Une directive située dans un autre fichier peut prendre le dessus. Un drop-in systemd peut modifier un service. SSH peut charger un Include oublié. Une valeur sysctl peut avoir été changée à chaud sans être persistante. Et une automatisation peut parfaitement se terminer sans erreur tout en laissant la machine dans un état différent de celui imaginé.

C’est exactement le problème auquel s’attaque Pavois , un projet open source développé par l’ingénieur DevOps français Stéphane Robert et rendu public le 16 septembre 2026. Plutôt que de simplement lire les fichiers présents sur le disque, l’outil interroge les services et le noyau pour vérifier ce que la machine applique réellement.

Lire sshd_config, c’est bien. Demander directement à SSH, c’est mieux

Prenons SSH. Un scanner de conformité classique peut ouvrir sshd_config, chercher une directive particulière et déterminer si elle semble correcte.

Pavois préfère demander directement à OpenSSH avec sshd -T, ce qui permet d’obtenir la configuration finale après interprétation des fichiers inclus et des différentes règles. Pour le noyau, il s’appuie sur l’état retourné par sysctl. Pour systemd, il peut examiner systemctl show, et pour auditd les règles réellement chargées avec auditctl.

La différence paraît subtile, mais elle ne l’est pas vraiment.

Imaginez qu’un administrateur configure correctement SSH, puis qu’un autre paquet ajoute six mois plus tard un fichier dans sshd_config.d/ qui modifie un paramètre sensible. Le fichier principal est toujours impeccable. L’état effectif, lui, ne l’est plus.

Un outil qui inspecte uniquement le premier peut vous rendre un joli feu vert.

Pavois essaie plutôt de vérifier le résultat final.

Et pour un outil censé vous dire si une machine est sécurisée, c’est quand même une assez bonne idée.

ANSSI, CIS, NIST, PCI DSS et STIG dans le même moteur

Pavois ne se contente pas d’inventer sa propre liste de bonnes pratiques. Son corpus de contrôles peut être relié à plusieurs référentiels de sécurité connus, notamment CIS, ANSSI BP-028, NIST, PCI DSS et DISA STIG.

L’idée n’est cependant pas d’exécuter cinq fois la même vérification parce que cinq normes demandent sensiblement la même chose. Le projet utilise une référence intermédiaire baptisée SOCLE : un contrôle technique unique peut être associé aux exigences correspondantes dans plusieurs standards.

Un contrôle portant sur le verrouillage des comptes après plusieurs mots de passe incorrects peut ainsi correspondre simultanément à une règle CIS, une recommandation ANSSI, une exigence NIST, une règle PCI DSS et un contrôle STIG.

Pour l’utilisateur, cela ne signifie pas qu’il faut devenir conforme à tout Internet d’un seul coup.

Si votre entreprise travaille uniquement avec les recommandations ANSSI, vous pouvez demander :

Et pour CIS :

Le projet insiste d’ailleurs sur un point important : un mapping vers une norme n’est pas une certification. Pavois produit des mesures et des preuves techniques. Il ne remplace ni un audit officiel ni l’organisme chargé de certifier votre infrastructure.

C’est probablement moins vendeur que d’écrire « DEVENez PCI-DSS EN UN CLIC », mais nettement plus sérieux.

Votre serveur reçoit une note de A à E

Après son analyse, Pavois produit une note comprise entre A et E. L’idée est de donner rapidement une vision de l’état général de la machine tout en permettant de descendre ensuite dans le détail des contrôles ayant échoué.

Mais le projet introduit une nuance intéressante : un paramètre correct maintenant n’est pas forcément un paramètre qui sera toujours correct après un redémarrage.

Prenons une valeur modifiée directement avec sysctl. Elle peut être parfaitement active en mémoire mais disparaître au prochain reboot si aucun fichier de configuration persistant ne la définit. Un scanner classique pourrait simplement afficher PASS.

Pavois qualifie ce résultat en distinguant l’état actif de sa persistance. Un contrôle qui fonctionne uniquement à l’exécution peut donc être considéré comme valide tout en empêchant la machine d’obtenir la meilleure note tant que sa persistance n’est pas démontrée.

Dit autrement : Pavois essaie de répondre non seulement à « est-ce sécurisé maintenant ? », mais aussi à « est-ce que ce sera toujours sécurisé après que quelqu’un aura redémarré le serveur à 3 heures du matin ? ».

Question rarement inutile.

Il ne fait pas qu’auditer : il peut aussi durcir la machine

Le projet propose également une fonction de hardening.

Après le scan, Pavois peut générer un plan de correction. L’administrateur choisit les règles qu’il souhaite appliquer, peut examiner le résultat avant modification puis lancer la convergence via le moteur CINC/Chef utilisé par le projet.

L’approche est volontairement différente d’un gigantesque script shell qui change 250 paramètres avant d’afficher « terminé » en vert.

Les remédiations sont sélectionnables et le projet propose un mode de prévisualisation. Pavois sait également produire un mécanisme de retour arrière pour une grande partie de ses modifications. Lors de son lancement public, l’auteur annonçait un taux de rollback mesuré de 96 % sur une Debian 12 fraîche, les modifications non réversibles étant explicitement signalées.

C’est particulièrement intéressant pour du durcissement système, parce qu’une recommandation de sécurité mal appliquée possède une étonnante capacité à transformer un serveur distant en presse-papier inaccessible par SSH.

Pouvoir savoir comment revenir en arrière avant de cliquer sur le bouton est donc plutôt appréciable.

Pas besoin d’installer un agent sur toute la flotte

Pavois repose sur CINC Auditor, la version libre et sans marque de Chef InSpec. L’outil peut analyser la machine locale, une cible distante en SSH ou encore un conteneur Docker.

Pour une machine distante, il réutilise le ~/.ssh/config de l’administrateur. L’idée est donc de ne pas déployer un agent permanent supplémentaire sur chaque serveur uniquement pour effectuer les audits.

Les commandes restent assez directes :

ou :

L’accès root ou sudo reste naturellement nécessaire pour inspecter correctement certains éléments comme SSH, les paramètres noyau ou auditd.

Et comme tout bon outil moderne qui veut finir dans une pipeline plutôt que sur une capture d’écran envoyée par mail, Pavois sait produire ses résultats en HTML, JSON, CSV, JUnit et SARIF. Il peut également utiliser un seuil --fail-under afin de faire échouer automatiquement une CI lorsque le serveur ou l’image construite n’atteint pas le niveau attendu.

Voilà qui devrait ravir tous ceux dont la définition du bonheur contient les mots « compliance gate dans GitLab CI ».

Les preuves peuvent aussi sortir de l’outil

Un autre aspect intéressant concerne la traçabilité.

Un rapport de conformité qui affirme simplement « PASS » possède une valeur limitée si personne ne sait précisément ce qui a été contrôlé, comment le résultat a été obtenu ni avec quelle version des règles.

Pavois propose donc plusieurs formats destinés à être exploités ailleurs, notamment OSCAL, SARIF et JSON. Le projet permet également de générer des bundles de preuves afin de conserver les éléments ayant servi au verdict.

C’est une approche plutôt adaptée aux environnements DevSecOps : le résultat de l’audit peut être archivé avec un build, analysé par une autre plateforme ou intégré à des outils de gouvernance et de conformité.

Le serveur n’est donc plus simplement « conforme parce que Michel a lancé un script mardi ».

Il existe un artefact associé au contrôle.

Michel peut enfin prendre ses RTT tranquille.

L’installation essaie elle aussi de ne pas vous demander une confiance aveugle

Pavois est distribué sous licence Apache 2.0. Les versions publiées proposent des binaires pour Linux et macOS en amd64 et arm64, ainsi que des paquets .deb et .rpm. Le corpus de règles est directement embarqué dans le binaire.

Le projet fournit également des checksums, un SBOM CycloneDX et une attestation de provenance SLSA. La documentation explique même la différence entre vérifier l’intégrité d’un fichier avec SHA-256 et vérifier l’identité de la chaîne qui l’a construit.

Un hash vous confirme en effet que le fichier téléchargé correspond au hash affiché.

Mais si un attaquant réussit à remplacer le binaire et le fichier contenant les hashes, les deux correspondent toujours parfaitement.

L’attestation de provenance sert justement à aller un peu plus loin en permettant de vérifier l’origine du build.

Pour un logiciel dont le métier consiste ensuite à lancer des commandes privilégiées sur des serveurs, ce genre de paranoïa est probablement une qualité professionnelle.

Le lancement n’a d’ailleurs pas été complètement tranquille

Un détail rend le projet plutôt sympathique : son auteur documente publiquement les problèmes rencontrés pendant son lancement.

Pavois est devenu public le 16 septembre 2026, mais les premières versions avaient un problème assez gênant : les tests avaient été réalisés directement depuis le dépôt Git, où les profils nécessaires étaient présents. Le binaire autonome téléchargé sur une machine propre, lui, ne disposait pas initialement de tout ce dont il avait besoin.

Résultat : cinq releases en trois jours pour stabiliser notamment cette chaîne de livraison.

Ce n’est pas le genre d’information habituellement placé en lettres géantes sur la page d’accueil d’un projet.

Mais dans le domaine de la sécurité, c’est plutôt sain. Un outil de conformité qui prétend n’avoir jamais fait d’erreur inspire généralement moins confiance qu’un projet qui explique clairement ce qu’il a cassé, pourquoi et comment il l’a corrigé.

Le billet de lancement comporte d’ailleurs plusieurs corrections datées au fur et à mesure des validations effectuées sur les différentes plateformes Linux.

Ce n’est pas encore le couteau suisse de toute votre infrastructure

Pavois reste un projet jeune et son auteur le reconnaît.

Il n’existe notamment pas encore de véritable console centralisée permettant de gérer toute une flotte depuis une interface unique. Une exécution analyse une cible, même s’il est naturellement possible d’automatiser plusieurs scans et d’agréger les fichiers JSON produits.

Le projet ne prétend pas non plus remplacer Ansible, Puppet ou votre outil de gestion de configuration. Ceux-ci décrivent ce que vous voulez obtenir. Pavois intervient plutôt après eux pour vérifier ce que la machine a réellement appliqué.

La distinction est intéressante.

Un playbook Ansible exécuté sans erreur signifie qu’Ansible pense avoir effectué les opérations demandées. Il ne garantit pas nécessairement qu’une autre configuration, une modification manuelle ou un service lancé avec des paramètres inattendus n’ait pas changé le résultat final.

Dans cette logique, Pavois ressemble davantage à l’inspecteur qui arrive après les travaux et vérifie que la rambarde est réellement fixée au mur.

Pas au fichier YAML qui affirme qu’elle devrait l’être.

Un outil particulièrement pertinent pour le Linux « sérieux »

Pour un Raspberry Pi qui héberge trois conteneurs dans le salon, comparer la machine à PCI DSS et au STIG américain est peut-être légèrement excessif.

Mais dès que Linux héberge des services professionnels, des données sensibles ou une infrastructure soumise à des exigences réglementaires, la question de la configuration réellement appliquée devient beaucoup plus intéressante.

Les environnements Linux modernes multiplient les couches : configuration principale, dossiers .d, variables d’environnement, options de lancement, paramètres temporaires, unités systemd, conteneurs et automatisations diverses. Vérifier uniquement la présence d’une ligne dans un fichier finit donc par donner une vision très partielle de la réalité.

Pavois prend le problème dans l’autre sens : regarder d’abord ce que le système fait, puis demander si cet état respecte la politique attendue.

L’approche est simple à comprendre, le projet est open source et le support natif d’ANSSI BP-028 lui donne en plus un intérêt particulier pour les administrateurs français.

Reste maintenant à voir comment l’outil évoluera avec davantage d’utilisateurs, de distributions testées et de véritables environnements de production.

Mais pour un projet public depuis seulement quelques jours, l’idée mérite clairement un tour dans une VM.

Au pire, votre serveur prendra un E.

Et contrairement au bulletin scolaire, celui-ci vous explique précisément pourquoi.