La transparence par l'audit
- Au sein du cadre normatif
- Des limites plus fondamentales de la transparence
- Dans l’échange, de quoi avons-nous besoin ?
- Mais alors… que devons-nous faire ?
- Conclusion
- Ressources
L’audit permet de garantir la transparence des processus et des décisions au sein d’une organisation. En documentant et en vérifiant les actions réalisées, il devient possible de rendre compte de manière claire et objective des pratiques en place. Cela renforce la confiance et la responsabilité.
Pourtant, l’audit place aussi l’entreprise dans une situation ambiguë. Elle doit trouver un équilibre délicat : en dire suffisamment pour couvrir les exigences de l’audit (description des services, gouvernance, sécurité, etc.), tout en limitant les informations susceptibles de créer une surface d’attaque. Autrement dit, elle doit éviter d’exposer les sujets qu’elle maîtrise le moins, qu’il s’agisse d’éléments trop anciens ou, au contraire, trop récents.
Afin de clarifier ce juste équilibre, nous allons rappeler les principes des audits, examiner les limites de la transparence qu’ils impliquent, puis proposer quelques pistes de bonnes pratiques pour concilier transparence et protection des informations sensibles.
Au sein du cadre normatif
La norme des normes : l’ISO 19011
« Un audit a pour objectif de fournir une assurance raisonnable que les risques sont maîtrisés, que les processus sont appliqués comme prévu, et que des mécanismes existent pour détecter et corriger les écarts. Cette démarche constitue l’un des principaux leviers d’amélioration continue des systèmes de management ISO. » – extrait de la norme ISO 19011
Concrètement, l’auditeur évalue la documentation du service, les processus de conception, de développement, de qualification et de déploiement, ainsi que le dispositif de gestion des changements (flux de qualification, d’approbation et de validation sécurité). L’audit porte donc davantage sur la capacité de l’organisation à démontrer qu’elle maîtrise ses propres processus que sur la capacité réelle du produit à fonctionner et à répondre aux attentes des utilisateurs.
L’audit est un événement ponctuel. Les équipes doivent préparer la documentation des processus et les preuves de leur exécution. Leur objectif consiste à montrer ces processus et à prouver qu’ils sont effectivement appliqués et maîtrisés. L’auditeur pourra également poser des questions dans ce sens.
L’entreprise peut ainsi soumettre un périmètre clairement défini et réaliser un travail préalable pour s’assurer que ce périmètre est correctement documenté et que les preuves nécessaires sont disponibles.
Selon les résultats, l’auditeur peut valider le renouvellement de la certification, éventuellement assorti de recommandations ou de non-conformités mineures ou majeures. L’entreprise s’engage alors à mettre en œuvre des actions correctives dans les délais impartis, faute de quoi la certification pourrait être suspendue ou retirée.
Ce mode de fonctionnement n’est pas exempt de failles.
Les limites de la norme
L’audit étant un événement ponctuel (tous les un à deux ans selon les cas), il ne garantit pas une surveillance continue des pratiques. Certaines non-conformités ou dérives peuvent donc passer inaperçues entre deux audits. Ce risque s’accroît lorsque les produits évoluent rapidement, surtout depuis l’essor de l’intelligence artificielle. La documentation fournie devient rapidement obsolète.
Par ailleurs, les audits valident des processus qui peuvent être formellement corrects tout en restant insuffisamment ou inefficacement appliqués dans la pratique. Autrement dit, les processus peuvent être conformes aux yeux de l’auditeur et pourtant inopérants au quotidien.
Le ciblage d’un périmètre spécifique crée aussi un biais de conformité. Les équipes ont tendance à concentrer leurs efforts sur les zones auditées, au détriment d’autres parties du système. Cela peut donner une impression de conformité globale alors que certaines pratiques restent défaillantes hors du périmètre examiné. S’y ajoute une asymétrie d’information : l’auditeur dispose d’un référentiel général, tandis que la connaissance fine du produit et de ses usages reste dispersée parmi les équipes et les utilisateurs.
Nous voyons ainsi émerger deux limites principales : la nature ponctuelle de l’audit, qui ne permet pas une surveillance continue, et le coût d’opportunité élevé lié à sa préparation et à sa réalisation.
Les remédiations pour rester efficace
Pour y remédier, nous pouvons automatiser autant que possible la documentation de notre service et nous concentrer sur les processus les plus fondamentaux.
Les documents demandés portent essentiellement sur l’architecture du système et sur les processus de déploiement et de maintenance. Ces éléments correspondent à des parties de l’application qui se prêtent bien à l’automatisation. L’architecture, par exemple, peut être pilotée avec des outils comme Terraform, qui permettent d’instrumenter l’infrastructure et de générer automatiquement la documentation correspondante. De même, les pipelines de déploiement automatisé, qui intègrent des phases de test, de qualification et de validation, peuvent être documentés directement à partir du code du pipeline.
Ces documents peuvent ainsi être maintenus à jour en continu, notamment en intégrant une étape dédiée dans les processus automatisés. Cette documentation présente d’ailleurs un intérêt interne : elle permet de produire des schémas clairs et accessibles, utiles pour les nouveaux membres de l’équipe ou pour faciliter la communication entre les différentes parties prenantes.
Les choix d’architecture reposent également sur des principes fondamentaux que nous avons déjà explorés par le passé, comme le Well-Architected Framework et les référentiels internes qui définissent les bonnes pratiques de robustesse, de sécurité et de maintenabilité. Ce sont précisément les types de documents qui intéressent un auditeur.
Les pipelines de déploiement constituent alors les preuves formelles que ces processus sont suivis et appliqués. Ils répondent ainsi à une bonne partie des attentes des audits.
Des limites plus fondamentales de la transparence
Ce que montre le label… et ce qu’il ne montre pas
Au-delà du coût en temps et en énergie, les mécanismes d’audit présentent des limites plus fondamentales. Qualiopi, à l’instar des normes ISO, en offre un exemple frappant : destiné aux centres de formation, il contrôle les procédures plutôt que le contenu du service.
Dans son essai Ce qu’on voit et ce qu’on ne voit pas (1850), Frédéric Bastiat montre qu’un acte économique produit toujours deux catégories d’effets : ceux qui sont immédiatement visibles et ceux qui restent invisibles.
Dans le cas des audits, nous voyons le label, la confiance apparente qu’il procure et l’activité économique générée autour de la certification (organismes certificateurs, consultants, équipes internes). Ce que nous ne voyons pas, c’est le coût réel supporté par l’entreprise : le financement des organismes de certification et l’effort interne déjà évoqué. Plus important encore, nous ne voyons pas l’écart éventuel avec la qualité effective du service rendu à l’utilisateur. Une certification peut attester que les procédures sont conformes tout en laissant dans l’ombre le fait que le produit répond mal aux besoins réels, ou que le coût de la conformité a détourné des ressources qui auraient pu améliorer l’expérience utilisateur.
Bastiat nous invite donc à ne pas nous arrêter à l’effet visible (le certificat) et à examiner aussi les effets invisibles (le coût d’opportunité et la valeur réellement délivrée).
Le système de certification repose également sur une délégation de confiance à des entités souvent déconnectées des intérêts des consommateurs. Nous nous retrouvons alors avec des critères de validation qui ne sont pas toujours en phase avec les besoins réels. C’est le problème d’un système trop lent – voire figé – face à une information dispersée chez chaque utilisateur et chaque client. C’est le rôle de l’entreprise de découvrir ces besoins, et non celui de l’auditeur.
Exposer le fonctionnement interne de l’entreprise ?
La plupart des audits demandent à l’entreprise d’exposer son fonctionnement interne. Et aujourd’hui, ceux-ci glissent de plus en plus sur des critères ESG (environnement, social et gouvernance), indépendamment de leur sujet d’origine. Nous sommes amenés à les aborder pour des normes comme l’ISO 42001, alors que cette dernière est censée porter sur l’intelligence artificielle.
Dans le cas de l’IA, nous pouvons légitimement nous intéresser aux éléments susceptibles d’introduire des biais, notamment les données et les méthodes d’entraînement. En revanche, le fonctionnement interne de l’entreprise ne concerne pas directement les utilisateurs finaux.
C’est en effet le problème de l’entreprise si elle optimise sa consommation pour améliorer ses marges, ou si elle traite mal ses propres fournisseurs (salariés comme partenaires). Ces derniers iront d’ailleurs chercher ailleurs des relations plus saines.
Au-delà de cela, toute donnée de l’entreprise exposée à l’extérieur devient plus facilement accessible. Plus une organisation révèle d’informations (architecture, dépendances, points faibles, processus internes), plus elle offre de prises à d’éventuels acteurs malveillants ou à des pressions commerciales et réglementaires.
Une documentation trop exhaustive peut donc engendrer plus d’inconvénients que de bénéfices. La transparence doit être calibrée : suffisamment large pour permettre une décision éclairée, suffisamment mesurée pour ne pas créer de vulnérabilités inutiles.
Et le plus beau dans l’histoire…
… c’est que nous n’avons aucune garantie que la documentation servira. C’est un phénomène que nous observons avec la plupart des produits. Nous avons beau proposer une documentation aussi complète que possible, beaucoup d’utilisateurs préfèrent découvrir le produit directement à l’usage.
Avant l’apparition de distributions comme Ubuntu ou d’environnements de bureau comme KDE, Linux a rebuté de nombreux néophytes par l’aspect austère de sa ligne de commande. Aujourd’hui, Bitcoin rencontre des limites similaires : malgré l’attrait de la liberté économique, l’aridité des notions de cryptographie sur lesquelles reposent ses technologies décourage encore beaucoup de novices.
Ces exemples montrent à quel point une documentation, aussi exhaustive soit-elle, ne suffit pas à rendre un produit accessible à son public.
Dans l’échange, de quoi avons-nous besoin ?
En tant qu’utilisateurs, nos critères de consommation portent sur la qualité du service qui nous est fourni, et non sur la façon dont il est produit.
Un produit devient le moyen de notre action s’il nous permet de répondre à notre besoin. Nous devons donc pouvoir évaluer, avec un degré raisonnable de confiance, dans quelle mesure cette valeur sera bien délivrée.
Au-delà, nous nous sentons potentiellement concernés par les risques majeurs associés à l’échange : la sécurité de nos données, la disponibilité du service au moment où nous en avons besoin, ou les risques de biais dans le cas d’une intelligence artificielle.
Tout le reste (détails internes de production, organisation des équipes, etc.) peut être utile dans certains contextes, comme des partenariats ou des collaborations étroites entre entreprises. Il n’est toutefois pas indispensable à la décision d’échanger.
Mais alors… que devons-nous faire ?
Pouvoir découvrir le service avant la prise en main
Ce premier point a déjà été abordé dans un précédent article) sur le PRD et les expérimentations produit. Tout moyen permettant au consommateur de prendre en main le produit et de fournir des retours est bénéfique, à la fois pour l’équipe et pour le consommateur. Cela lui permet d’évaluer dans quelle mesure le produit lui sera utile. Maquettes, prototypes, versions bêta peuvent atteindre des « early adopters », ces personnes susceptibles d’adopter un produit qui n’a pas encore fait toutes ses preuves. Elles serviront aussi de support de communication sur nos services.
Même après la stabilisation de nos services, nous pouvons proposer des accès partiels ou temporaires, souvent appelés « free tiers ». Lorsque cette approche est mal employée — par exemple sur des mécaniques addictives d’un jeu —, elle peut être perçue comme un piège. Bien utilisée, elle permet de découvrir les capacités du produit avant même de débourser un centime.
Faciliter la prise en main
Ce point apparaissait déjà en filigrane dans notre critique de la documentation produit. Il fait référence à un prolongement naturel entre le produit et la praxéologie de Ludwig von Mises, que nous avions déjà identifié.
La praxéologie s’intéresse à l’action humaine, à ses buts et aux moyens mis en œuvre pour les atteindre. Le produit se focalise précisément sur le moyen de cette action. L’un des leviers les plus évidents pour rendre un produit accessible consiste donc à soigner son ergonomie, c’est-à-dire tout ce qui rend son usage évident. Don Norman, référence en matière d’ergonomie, illustre ce principe avec la poignée de porte : c’est le moyen par excellence d’ouvrir une porte. Si nous la retirons, les utilisateurs auront besoin d’un temps d’adaptation avant de comprendre la nouvelle solution.
L’ergonomie est un vaste sujet qui relie culture, habitudes et notion de signifiant, thèmes que nous avions déjà abordés dans notre précédent article.
Il existe toutefois des cas limites où l’ergonomie ne suffit pas et où la documentation retrouve toute son utilité.
Lorsque la documentation devient utile
Souvent, la documentation intervient dans un second temps, pour des usages spécifiques. C’est le cas des API, où une référence complète est bienvenue, car elle constitue souvent le seul moyen de s’y retrouver. C’est aussi le cas des scénarios d’usage particulièrement complexes, lorsque le besoin est suffisamment fort pour que l’utilisateur accepte de s’engager malgré la difficulté.
Enfin, il reste le cas où le consommateur veut se prémunir des risques qui le concernent, comme pour ses données personnelles. Ici, des certifications centrées sur la robustesse et la sécurité des données restent pertinentes pour les protéger contre d’éventuelles failles susceptibles d’exposer leurs informations. Dans ces cas, les moyens proposés en début d’article pour produire la documentation d’audit conservent tout leur intérêt.
Conclusion
Ainsi, certaines certifications, bien auditées et bien préparées, vont permettre à l’entreprise de montrer que les données des utilisateurs sont entre de bonnes mains. Face aux défis spécifiques de l’IA, c’est également un moyen d’anticiper les éventuels risques de dérives comme les biais ou les hallucinations.
Mais les audits actuels ne permettent pas de couvrir la raison principale pour laquelle l’entreprise et les entrepreneurs proposent leurs services : répondre aux besoins des utilisateurs. Ce sujet ne pourra pas être couvert par les audits, et rarement par la documentation, car ces besoins sont spécifiques et fluctuent au gré des marchés.
À ce moment-là reste le dernier remède, qui consiste à montrer que le produit répond à ce besoin. Grâce à des démonstrations, des free tiers et une ergonomie facilitant l’accès aux services rendus, les consommateurs sauront ce qu’ils s’apprêtent à consommer.
Ressources
- ISO 19011:2018 (et versions ultérieures) – Guidelines for auditing management systems (Lignes directrices pour l’audit des systèmes de management).
- ISO/IEC 27001 – Systèmes de management de la sécurité de l’information.
- ISO/IEC 42001 – Systèmes de management de l’intelligence artificielle.
- Référentiel National Qualité (Qualiopi) – textes officiels relatifs à la certification des prestataires d’actions concourant au développement des compétences.
- L’Action humaine : Traité d’économie, de Ludwig von Mises.
- Frédéric Bastiat, Ce qu’on voit et ce qu’on ne voit pas (1850).
- The Design of Everyday Things (Revised and expanded edition), de Don Norman
Write a comment