Questions fréquemment posées

La Fondation LibreKAT travaille sur la sécurité des informations ouverte, contrôlable et vérifiable. La fondation soutient des projets, le partage de connaissances et la collaboration autour de la sécurité numérique.

Il ne s’agit pas seulement de logiciels. LibreKAT souhaite également contribuer à de meilleures pratiques de travail, à plus de transparence et à une communauté dans laquelle les gens peuvent améliorer ensemble la sécurité numérique.

En savoir plus sur À propos de la Fondation LibreKAT.

La sécurité numérique est trop importante pour dépendre entièrement de systèmes fermés, de processus incontrôlables ou de promesses vagues. Les organisations doivent être capables de comprendre, contrôler et améliorer le fonctionnement de leur sécurité.

LibreKAT existe pour promouvoir cela. La fondation encourage la technologie ouverte, le partage des connaissances et la collaboration entre les personnes souhaitant accroître la résilience numérique.

Lisez également Quels sont les objectifs de la Fondation LibreKAT ? et À propos de la Fondation LibreKAT.

Non. LibreKAT est une fondation et n’a aucun objectif lucratif. La fondation peut collaborer avec des entreprises, des gouvernements, des chercheurs, des bénévoles et des organisations sociales.

L’objectif principal de la collaboration est de contribuer à une sécurité numérique ouverte, durable et vérifiable.

En savoir plus sur À propos de la Fondation LibreKAT.

Libre fait référence à la liberté. Pas seulement une utilisation gratuite, mais surtout la liberté d’étudier, de contrôler, d’adapter et de partager la technologie.

Ceci est important pour la sécurité des informations. Si vous souhaitez vous appuyer sur un système ou une méthode, vous devez être capable de voir comment il fonctionne et comment les décisions sont prises.

Cela rejoint le valeurs fondamentales de la Fondation LibreKAT.

La Fondation LibreKAT souhaite améliorer la sécurité numérique en encourageant une sécurité des informations ouverte, contrôlable et vérifiable.

Concrètement, cela comprend :

• développement et utilisation de logiciels et matériels open source pour des infrastructures numériques sécurisées ;
• transparence et reproductibilité des processus de sécurité ;
• recherches, formations et activités sur la résilience numérique ;
• connexion entre les citoyens, les entreprises, le gouvernement et les organisations sociales.

En savoir plus sur À propos de la Fondation LibreKAT et sur le page d’accueil de la Fondation LibreKAT.

LibreKAT est la fondation. OpenKAT est un produit d’analyse de vulnérabilité open source.

Les noms sont similaires, mais ne signifient pas la même chose. La fondation peut prendre en charge OpenKAT et OpenKAT s’inscrit dans la mission de LibreKAT, mais OpenKAT n’est pas la fondation elle-même.

En savoir plus sur Fondation LibreKAT et OuvrirKAT.

L’Open Source rend le contrôle possible. Les utilisateurs peuvent voir comment fonctionne le logiciel, trouver des erreurs, suggérer des améliorations et réduire la dépendance à l’égard d’un seul fournisseur.

L’open source n’est pas une garantie automatique de sécurité. C’est une condition importante pour la transparence, la coopération et la restauabilité.

Apprenez-en davantage sur les principes sur À propos de la Fondation LibreKAT.

Les projets importants sur ce site sont OpenKAT, MIAUW et OciDeck.

OpenKAT contribue à rendre visibles les vulnérabilités et les risques numériques. MIAUW contribue à rendre la recherche sur la sécurité de l’information vérifiable et digne d’un audit. OciDeck facilite les présentations structurées, les rapports et le partage sécurisé d’informations.

En savoir plus sur OuvrirKAT, MIAUW et OciDeck.

LibreKAT s’adresse à tous ceux qui souhaitent rendre la sécurité numérique ouverte, vérifiable et plus explicable.

Pensez aux professionnels de la sécurité, aux développeurs, aux administrateurs, aux auditeurs, aux chercheurs, aux gouvernements, aux entreprises, aux établissements d’enseignement, aux organisations sociales et aux citoyens impliqués.

En savoir plus sur À propos de la Fondation LibreKAT.

Oui. Vous pouvez participer de plusieurs manières : contribuer au code, améliorer la documentation, tester, traduire, poser des questions, partager des expériences ou aider aux réunions et aux activités communautaires.

Vous n’avez pas besoin de tout savoir techniquement pour apporter une contribution précieuse. De bonnes questions, une expérience pratique et des explications claires sont également importantes.

Contactez-nous au Contact.

Cela est possible si la collaboration correspond aux objectifs de la fondation. LibreKAT recherche une collaboration qui contribue à une sécurité numérique ouverte, durable et vérifiable.

Les exemples sont le partage de connaissances, la recherche, le développement open source, la documentation, la formation ou les applications pratiques des projets.

Voir également Partenaires et Contact.

Les valeurs importantes sont la sécurité, la liberté, l’ouverture, la souveraineté, l’intégrité, le partage des connaissances, la coopération, l’humanité et la continuité.

En langage clair : LibreKAT veut que la sécurité numérique soit vérifiable, juste, durable et utilisable pour les personnes et les organisations qui en dépendent.

Lisez également l’article À propos de nos valeurs fondamentales.

Utilisez le page de contact si vous avez une question, souhaitez contribuer ou discuter de collaboration.

Essayez de décrire brièvement le sujet de votre question : fondation, MIAUW, OpenKAT, OciDeck, collaboration, presse ou contribution technique. On saura alors plus clairement qui peut répondre.

Une culture juste est une culture organisationnelle dans laquelle les individus peuvent signaler des problèmes de sécurité, des erreurs et des quasi-incidents sans chercher automatiquement un responsable. L’organisation utilise les informations pour comprendre ce qui s’est passé et pour améliorer les personnes, la technologie, les méthodes de travail et l’organisation.

Cela ne veut pas dire que tout comportement est acceptable. Une culture juste indique clairement à l’avance où se situent les limites et évalue le comportement avec soin, cohérence et contexte. Les règles européennes de l’aviation définissent cela comme une culture dans laquelle les employés ne sont pas punis pour des actions conformes à leur formation et à leur expérience, tandis que la négligence grave et les violations intentionnelles ne sont pas tolérées. Voir Règlement (UE) 376/2014.

L’élaboration moderne vient de la science de la sécurité entourant les organisations complexes et à haut risque. Le psychologue James Reason a décrit la culture juste en 1997 comme faisant partie d’une culture de sécurité informée, en plus d’une culture de reporting, d’une culture d’apprentissage et d’une culture flexible.

L’aviation en particulier a mis ce principe en pratique. Les accidents et quasi-accidents ne peuvent faire l’objet d’enquêtes que lorsque les pilotes, les contrôleurs aériens, les techniciens et autres osent partager des informations. Les organisations aéronautiques ont donc développé des systèmes de reporting qui ne punissent pas automatiquement les erreurs courantes, mais fixent des limites aux comportements intentionnels ou imprudents. SKYbrary décrit ce développement ; l’Union européenne a établi ce principe dans règles relatives aux comptes rendus d’événements dans l’aviation civile en 2014.

Par la suite, la culture juste a également été appliquée aux soins de santé, aux chemins de fer, à l’énergie et à d’autres secteurs où il est important de tirer des leçons des signaux faibles. Il ne s’agit donc pas d’une procédure aéronautique copiée individuellement, mais d’un principe plus large permettant de gérer les erreurs et les risques de manière équitable et axée sur l’apprentissage.

Non. Une culture juste empêche qu’un rapport honnête, une simple erreur ou une violation involontaire conduise automatiquement à une sanction. Un coaching, un accompagnement supplémentaire ou une méthode de travail adaptée peuvent être nécessaires ; Il s’agit de mesures visant à garantir un travail sûr et non de sanctions automatiques.

En cas de faute intentionnelle, de sabotage, d’imprudence délibérée ou de méconnaissance grave d’un risque évident, des mesures contre une personne peuvent être appropriées. Cela nécessite d’abord une enquête honnête sur les faits, les circonstances, la formation, les ressources disponibles et les décisions antérieures comparables. La culture juste n’accorde pas non plus d’immunité juridique : la loi applicable continue de s’appliquer. Ce solde se trouve dans Article 16 du règlement (UE) 376/2014.

Non. Un modèle totalement « sans reproche » peut laisser de côté la responsabilité et les comportements inacceptables. La culture juste cherche une frontière équitable entre le comportement dont l’organisation doit tirer des leçons et le comportement dont elle doit s’adresser à une personne.

La première question n’est pas « qui pouvons-nous punir ? », mais « que s’est-il passé, pourquoi cette action semblait-elle logique à l’époque et quelles circonstances ont joué un rôle ? ». Ce n’est qu’à ce moment-là que se pose la question de savoir si le comportement se situe dans les limites connues et appliquées de manière cohérente.

Non. Les employés restent responsables d’agir avec prudence, de signaler et de coopérer aux enquêtes. Les managers sont responsables d’objectifs réalistes, de ressources suffisantes, de limites claires et de la résolution des problèmes structurels.

La responsabilité signifie que les choix et les circonstances peuvent être discutés et contrôlés. Attribuer un blâme est un jugement sur la culpabilité. Une culture juste sépare les deux, de sorte que la responsabilité ne disparaisse pas mais soit répartie plus équitablement.

L’erreur humaine n’est pas intentionnelle. Un comportement à risque peut survenir parce que quelqu’un sous-estime un risque, qu’une habitude dangereuse est devenue normale ou que les objectifs sont en conflit les uns avec les autres. Une conduite imprudente implique un mépris conscient et sérieux d’un risque évident. Les actions intentionnellement nuisibles constituent une autre catégorie.

Ces mots ne sont pas des résultats automatiques. Une enquête minutieuse examine la formation, les informations disponibles, la charge de travail, la conception technique, les procédures, les signaux précédents et la manière dont d’autres ont agi dans la même situation. La gravité des dégâts à elle seule ne prouve pas que le comportement était imprudent.

Les employés sont tenus de signaler les erreurs, les risques et les quasi-incidents en temps opportun, d’exprimer leurs incertitudes, de coopérer à la recherche et de partager leurs connaissances pertinentes. Les managers sont censés écouter sans jugement prématuré, protéger les journalistes, enquêter sur les faits et le contexte et fournir des commentaires sur le sort d’un rapport.

L’organisation doit remédier aux causes structurelles, traiter les cas comparables sur un pied d’égalité et indiquer clairement à l’avance quel comportement est inacceptable. Dissimuler, riposter, juger seul du résultat ou laisser persister des risques connus ne cadre pas avec une culture juste.

La sécurité de l’information dépend de signaux précoces. Pensez à un lien de phishing ouvert, à un accès mal configuré, à un fichier presque divulgué, à une solution d’urgence dangereuse ou à une vulnérabilité découverte accidentellement par quelqu’un. La crainte de sanctions ou d’atteinte à la réputation peut conduire à ce que ces informations soient communiquées trop tard, voire pas du tout.

Une culture juste abaisse ce seuil et permet une enquête et une récupération plus rapides. Cela ne remplace pas les mesures de sécurité, la réponse aux incidents, les obligations de signalement ou les mesures contre les abus. Cela garantit que l’organisation reçoit des informations plus fiables pour utiliser ces instruments de manière ciblée.

Les gens travaillent dans le respect d’objectifs, d’outils, de procédures, de contraintes de temps et de limites techniques. Si plusieurs personnes peuvent commettre la même erreur, s’adresser uniquement à la dernière personne n’est pas une solution complète. Les mêmes conditions peuvent alors provoquer à nouveau le problème.

Par conséquent, une culture juste examine également la conception du système, les droits d’accès, la formation, la charge de travail, la supervision, les objectifs contradictoires et les signaux antérieurs. Cela n’exclut pas la responsabilité individuelle. Cela empêche une action humaine visible de dissimuler des causes plus profondes.

Un pen test peut affecter le comportement des employés, des administrateurs ou des fournisseurs. MIAUW exige qu’une conclusion soit étayée par des preuves, sa portée et son contexte. Un rapport doit donc décrire les faits et les conséquences observables et ne pas attribuer d’intentions ou de culpabilité personnelle sans enquête.

La culture juste aide à utiliser les résultats pour le rétablissement : quelles conditions techniques ou organisationnelles ont rendu le problème possible, quelle mesure réduit la récidive et à qui appartient cette mesure ? Si une action individuelle semble appropriée, cela nécessite un processus distinct et équitable ; un résultat de test d’écriture à lui seul n’en est pas une preuve.

Décrivez d’abord ce qui s’est manifestement produit, quand, dans quelle mesure et avec quelles conséquences. Enregistrez ensuite les circonstances pertinentes, telles que les informations disponibles, les instructions, la charge de travail, les droits d’accès et la sécurité technique. Expliquez clairement ce qu’est un fait, une déclaration et une hypothèse non confirmée.

Utilisez un nom uniquement lorsque l’identification est nécessaire et proportionnée. Des formulations telles que « un compte a pu effectuer l’action » sont souvent plus informatives que « l’employé X a provoqué l’incident ». Le cas échéant, donnez aux personnes impliquées la possibilité de corriger les inexactitudes factuelles ou le contexte manquant.

La responsabilité individuelle peut être nécessaire en cas de comportement intentionnel nuisible, de sabotage délibéré, de tromperie ou de méconnaissance grave et fautive d’un risque évident. Même dans ce cas, le jugement doit découler des faits, entendre les deux parties, connaître des règles connues et donner une réponse proportionnée.

L’effet d’un acte ne suffit pas à établir la culpabilité. Une petite erreur peut accidentellement causer des dégâts importants, tandis qu’un comportement imprudent se termine parfois sans dommage. Une culture juste évalue donc le comportement et le contexte, et pas seulement la chance ou la malchance dans le résultat.

Une culture juste bien appliquée peut accroître la volonté de signaler les erreurs, les risques et les quasi-incidents. Cela permet à une organisation de mieux comprendre les signaux faibles plus tôt, de reconnaître les modèles récurrents et de concentrer les mesures sur les causes plutôt que uniquement sur la dernière personne de la chaîne.

D’autres avantages possibles incluent une confiance accrue, de meilleures conversations sur la sécurité, un soutien aux employés engagés et une amélioration continue des processus. Ces effets ne proviennent pas uniquement de l’étiquette. A examen récent de la portée de 36 interventions de soins de santé a trouvé de tels résultats, mais souligne également qu’il est encore difficile de déterminer exactement quels composants provoquent quel effet. La culture juste est donc une méthode de travail qui favorise l’apprentissage, et non une garantie de moins d’incidents.

Examinez la qualité et la distribution des rapports, le délai de retour d’information, le pourcentage de mesures d’amélioration achevées, la récurrence d’événements similaires et l’équité perçue de la recherche. Les employés doivent savoir où se situent les limites et être sûrs que des cas similaires seront traités de la même manière.

Un nombre croissant de signalements peut être au départ un bon signe : des informations auparavant cachées deviennent visibles. Le simple décompte des signalements ne suffit donc pas. Vérifiez également si l’organisation en tire des leçons, soutient les journalistes, s’attaque aux causes structurelles et motive les décisions de manière imitable.

Non. La culture juste a été fortement développée dans le secteur de l’aviation et a ensuite été appliquée aux soins de santé, entre autres, car les erreurs peuvent avoir des conséquences majeures et un signalement précoce est vital. L’essentiel – être capable de signaler en toute sécurité, d’évaluer le comportement honnêtement et dans son contexte et d’améliorer le système – est également utile dans la sécurité de l’information, le développement de logiciels, les services publics et d’autres organisations dans lesquelles les gens travaillent avec des systèmes complexes.

L’élaboration doit convenir à l’organisation. Une petite fondation a des rôles, des risques et des obligations juridiques différents de ceux d’une compagnie aérienne. Par conséquent, adoptez les principes, mais créez vous-même des itinéraires de reporting, des pouvoirs, des limites comportementales et des garanties clairs. La récente [revue de la portée de la culture juste dans les soins de santé] (https://pubmed.ncbi.nlm.nih.gov/41612347/) montre également que les interventions étudiées varient et que les preuves d’une mise en œuvre réussie sont encore limitées.

La sécurité psychologique signifie que les membres d’une équipe osent prendre des risques interpersonnels : poser une question, exprimer un doute, admettre une erreur ou donner une opinion différente. La culture juste est plus spécifique sur ce que l’organisation fait ensuite avec un rapport ou un événement : comment elle enquête, évalue le comportement, protège les journalistes, répartit les responsabilités et met en œuvre des améliorations.

Les concepts se renforcent les uns les autres, mais ne sont pas les mêmes. Une équipe agréable sans évaluation claire et cohérente n’est pas encore une culture juste. À l’inverse, un bon document politique ne fonctionne pas si les gens n’osent pas s’exprimer dans la pratique. Les recherches sur la sécurité psychologique mentionnent comme conditions importantes un leadership inclusif, un soutien et une orientation vers l’apprentissage. Voir cette revue systématique.

Les managers définissent des attentes claires, réagissent calmement aux mauvaises nouvelles et veillent à ce que les signalements fassent l’objet d’une enquête indépendante et experte. Ils demandent d’abord ce qui s’est passé et quelles circonstances ont joué un rôle avant de tirer des conclusions sur les personnes. Ils libèrent également du temps, des personnes et du budget pour des mesures d’amélioration et fournissent des commentaires sur ce qui a été fait avec les rapports.

Leurs propres actions doivent également pouvoir faire l’objet d’une enquête. Si seuls les cadres sont concernés et que les choix concernant la charge de travail, les ressources ou les objectifs flous restent hors de propos, la culture n’est pas juste. Le [Guide de l’AHRQ sur les enquêtes sur les incidents basés sur le système] (https://www.ahrq.gov/patient-safety/settings/hospital/candor/modules/guide4.html) met l’accent à la fois sur le soutien des dirigeants et sur la recherche des faits plutôt que sur la recherche des reproches.

Les employés signalent les erreurs pertinentes, les quasi-incidents, les conditions dangereuses et les doutes aussi rapidement et de manière factuelle que possible. Ils participent à la recherche, partagent également des informations qui peuvent être inconfortables et contribuent à apporter des améliorations utiles à la pratique quotidienne. Ils abordent leurs collègues avec respect et demandent de l’aide lorsque les connaissances, le temps ou les ressources sont insuffisants.

La culture juste n’exige ni la perfection ni l’héroïsme. Un employé reste responsable d’agir avec prudence dans le cadre de son rôle, mais l’organisation reste responsable d’un système fonctionnel, d’une formation appropriée et de conditions réalistes. La responsabilité est donc partagée et non transférée.

Tout d’abord, les personnes et les systèmes sont sécurisés et la réception du rapport est confirmée. Une personne autorisée détermine ensuite qui traitera le rapport, quelles informations sont nécessaires et quelle confidentialité peut être assurée. La recherche reconstitue l’événement, implique les personnes concernées et examine les facteurs techniques, humains et organisationnels.

Les résultats et les mesures sont ensuite enregistrés, les personnes impliquées reçoivent un retour d’information approprié et il est vérifié si les mesures ont effectivement été mises en œuvre et fonctionnent. Un rapport sans suite visible nuit à la confiance. Les recherches sur les systèmes de signalement des incidents mettent en garde contre le fait que la collecte seule est insuffisante ; ce sont précisément les actions d’amélioration et un cycle d’apprentissage fermé qui déterminent la valeur. Voir cette revue systématique.

L’enquête commence par un calendrier et des faits vérifiables, et non par un coupable présumé. Les chercheurs parlent respectueusement aux personnes impliquées, testent diverses déclarations et examinent les procédures, la formation, les outils, la charge de travail, la communication, les choix de conception et les signaux antérieurs. Ce qui reste incertain est également enregistré.

Toute personne personnellement impliquée ou en conflit d’intérêts ne devrait pas décider seule du résultat. Les personnes impliquées doivent être en mesure d’expliquer les faits pertinents et de faire corriger les inexactitudes factuelles. La mesure choisie doit être adaptée au comportement et aux circonstances, et les cas comparables doivent être traités de la même manière. Des mesures de sécurité urgentes peuvent être nécessaires entre-temps, mais ne doivent pas être présentées comme une sanction déguisée.

L’organisation détermine à l’avance qui évalue les comportements, selon quels critères et avec quelle possibilité de contradiction ou de reconsidération. En fonction de la gravité, un responsable, un responsable de la sécurité, des RH, un expert en la matière, un représentant des salariés ou un comité indépendant peuvent être impliqués. Les questions juridiques appartiennent à une personne possédant l’expertise appropriée.

Les évaluateurs examinent non seulement le résultat, mais également la prévisibilité, l’intention, les connaissances, la formation, les alternatives disponibles et les circonstances au moment de l’action. Une issue grave ne prouve pas en soi un comportement imprudent ; un bon résultat ne rend pas acceptable un comportement consciemment dangereux.

Ne considérez pas le doute comme une preuve contre la personne concernée. Rassemblez des faits supplémentaires, demandez à quelqu’un ayant des connaissances spécialisées d’examiner les véritables options d’action et de vérifier si d’autres auraient pu faire un choix similaire dans les mêmes circonstances. Distinguer ce qui est visible après coup et ce que la personne aurait raisonnablement pu savoir à ce moment-là.

Enregistrez le compromis et l’incertitude restante. Une mesure drastique du personnel nécessite un processus plus rigoureux et indépendant, avec une audience et la possibilité de réexaminer la situation. De plus, résoudre immédiatement les faiblesses du système ; un désaccord sur la responsabilité individuelle ne constitue pas une raison pour qu’il existe un problème de sécurité démontrable.

Le signalement confidentiel signifie que l’identité n’est connue que des personnes qui en ont besoin dans le cadre d’un processus minutieux. Le signalement anonyme signifie que le destinataire ne connaît pas l’identité. La confidentialité permet d’autres questions et commentaires personnels ; l’anonymat peut abaisser le seuil si quelqu’un craint des représailles ou des conflits d’intérêts.

Proposez les deux itinéraires le cas échéant et expliquez honnêtement à l’avance ce qui peut et ne peut pas être protégé. L’anonymat complet ne peut pas toujours être garanti techniquement ou légalement, et les détails d’un événement peuvent indirectement rendre quelqu’un reconnaissable. Par conséquent, ne collectez pas plus de données personnelles que nécessaire et limitez les périodes d’accès et de conservation. Les règles européennes de l’aviation mentionnent la protection et la suppression des données d’identification comme moyens de renforcer la confiance dans les systèmes de reporting. Voir l’explication de l’AESA concernant le règlement 376/2014.

La culture juste et la protection des lanceurs d’alerte ont un objectif connexe : les gens devraient pouvoir signaler des problèmes graves sans être injustement désavantagés. Cependant, ils ne sont pas les mêmes sur le plan juridique et pratiquement. Un accord interne sur une culture juste ne peut jamais remplacer les droits légaux, un canal de signalement externe ou une protection contre les représailles.

Assurez-vous que les employés, les sous-traitants et les bénévoles sachent quel canal correspond à quel signalement et où ils peuvent obtenir des conseils indépendants. Ne traitez pas un signalement comme un problème de fidélité et n’essayez pas de bloquer contractuellement un canal externe légalement autorisé. La protection précise dépend de la loi applicable. La [Directive européenne sur les lanceurs d’alerte] (https://eur-lex.europa.eu/legal-content/en/LSU/?uri=CELEX%3A02019L1937-20230502) comprend des règles sur les canaux confidentiels, le suivi et la protection contre les représailles.

Non. Les obligations de signaler un incident, une violation de données, une suspicion d’infraction pénale ou tout autre événement continuent de s’appliquer. Un superviseur, un juge ou un employeur autorisé conserve également son rôle juridique. La culture juste ne stipule pas que les informations doivent toujours rester secrètes et n’accorde pas d’immunité.

Cependant, la culture juste nécessite des procédures claires, proportionnées et cohérentes : séparer l’apprentissage de la prise de décision disciplinaire lorsque cela est possible, limiter l’accès aux informations de déclaration et expliquer quand la déclaration peut être obligatoire. Adaptez l’approche au droit du travail, au droit de la vie privée, aux règles de dénonciation, aux règles sectorielles et à la participation existante des salariés. En cas de doute, faites évaluer juridiquement la situation spécifique.

Commencez par déterminer comment les gens signalent actuellement, où il y a de la peur ou de l’incertitude et comment les cas précédents ont été traités. Élaborez ensuite des règles simples avec les employés et les représentants concernés : que signalez-vous, par quel canal, qui a accès à l’information, comment se déroule l’enquête, où se situe la limite comportementale et comment quelqu’un peut-il faire reconsidérer une décision.

Former les managers et les chercheurs avec des exemples réalistes. Pratiquez le processus, traitez les premiers rapports avec une attention visible et publiez les points d’apprentissage et les progrès de manière anonyme. Mesurez la confiance, effectuez le suivi et ajustez le processus. Mieux vaut commencer petit et complet qu’avec un grand programme sans capacité. L’AESA conseille aux organisations d’inclure des processus clairs de culture juste dans leurs politiques de sécurité et d’impliquer les représentants des employés. Voir le [Guide de l’EASA pour les systèmes de reporting] (https://www.easa.europa.eu/en/faq/98235).

Les erreurs courantes incluent : assimiler la culture juste au fait de ne jamais s’exprimer, fixer des limites seulement après un incident, confondre la gravité du résultat avec la culpabilité du comportement, examiner uniquement la dernière action humaine et traiter des cas similaires différemment. La large diffusion de noms, les fuites d’informations dans les rapports et un manager qui est à la fois directement impliqué, chercheur et décideur, nuisent également à la confiance.

Un autre écueil est de demander des rapports mais de ne pas fournir de commentaires ou d’améliorations. Le journaliste assume alors le risque tandis que l’organisation ne tient pas sa promesse d’apprentissage. Le remède est vérifiable : rôles clairs, protection des informations, retours d’information en temps opportun, actions d’amélioration visibles et tests périodiques de cohérence.

Une culture juste axée sur le rétablissement ne s’intéresse pas seulement aux règles, aux causes et aux mesures de prévention futures, mais également aux dommages que les personnes et les relations ont subis à la suite d’un événement et à la réponse qui y a été apportée. Les questions incluent : qui a été touché, de quoi ont-ils besoin, qui a le devoir de restaurer quelque chose et comment la confiance peut-elle être rétablie de manière responsable ?

Cela peut conduire à une reconnaissance, une explication, une aide pratique, un rétablissement des accords de travail ou une conversation guidée. La participation doit être prudente et appropriée ; le rétablissement ne doit pas devenir un moyen de pression pour imposer le pardon, le silence ou la renonciation à ses droits. La littérature scientifique sur la culture juste réparatrice se multiplie, mais l’examen de la portée de 2026 conclut que les preuves sur les interventions et leur mise en œuvre réussie sont encore limitées.

Demandez séparément ce dont ont besoin les personnes directement concernées, les journalistes et les autres parties impliquées. Pensez à des informations factuelles, un interlocuteur permanent, du repos ou des tâches adaptées, du soutien par les pairs et l’accès à une aide professionnelle. Expliquez ce que la recherche peut et ne peut pas faire et quand les commentaires seront fournis. Évitez la spéculation et protégez les données personnelles.

Le soutien n’est pas un jugement de culpabilité et ne doit pas dépendre d’un comportement ultérieur. Parallèlement, une mesure de sécurité temporaire peut être nécessaire, par exemple une surveillance supplémentaire ou une autre tâche. Justifiez une telle mesure, limitez-la au nécessaire et réévaluez-la dès que davantage de faits seront connus.

Lors d’un quasi-accident, quelque chose s’est mal passé ou un danger est apparu, mais les dommages graves n’ont pas été causés par le hasard, une intervention opportune ou un niveau de sécurité supplémentaire. C’est alors qu’une organisation peut apprendre sans que personne n’ait à en supporter d’abord toutes les conséquences. Des détours récurrents, des instructions peu claires et des écarts mineurs peuvent également être les premiers signes d’un problème système.

Par conséquent, ne vous contentez pas de demander « qu’est-ce qui n’a pas fonctionné ? », mais aussi « qu’est-ce qui a fait que tout s’est bien passé ? et « quelle barrière a fonctionné ? ». Facilitez la création de rapports et fournissez des commentaires. Une revue systématique des quasi-accidents dans le domaine des soins de santé a révélé que le soutien des dirigeants, des itinéraires de signalement simples, les connaissances et une réponse non punitive influencent le comportement de signalement. Voir la revue sur PubMed.

Ne limitez pas la culture juste aux salariés ayant un contrat à durée indéterminée. Les fournisseurs, entrepreneurs, chercheurs, stagiaires et bénévoles peuvent être les premiers à constater une vulnérabilité, une erreur ou une situation dangereuse. Donnez-leur un itinéraire de signalement compréhensible, expliquez quelle protection s’applique et indiquez clairement dans les accords qui enquêtera et fournira des commentaires.

L’organisation ne peut pas contrôler unilatéralement l’ensemble du droit du travail ou les conséquences contractuelles chez une autre partie. Par conséquent, convenez à l’avance de la manière dont les informations seront protégées, du moment où elles seront partagées et de la manière dont les représailles ou les conflits d’intérêts seront évités. Outre les salariés, les règles européennes de l’aviation font également référence au personnel embauché ; les Règles de l’UE en matière de lancement d’alerte peuvent également inclure, dans leur champ d’application, les bénévoles, les travailleurs indépendants et les entrepreneurs.

Non. La souveraineté n’est pas une autarcie et n’exige pas une indépendance totale. Les organisations et les États dépendent toujours du savoir, des fournisseurs, des matières premières et de la coopération.

L’objectif est que les dépendances soient visibles, gérables et remplaçables si nécessaire. Vous pouvez externaliser le travail tout en gardant le contrôle, à condition que les responsabilités, les droits, les options d’accès, de continuité et de sortie soient correctement organisés.

Non. Aucun produit ne peut à lui seul garantir la souveraineté numérique. La souveraineté naît de la combinaison de la gouvernance, des contrats, de la compétence, de l’architecture, de l’ouverture, des connaissances, de la gestion et des alternatives réalisables.

OpenKAT et OciDeck peuvent fournir des éléments de base concrets : plus d’informations, de vérifiabilité, de formats ouverts, d’autogestion et moins de dépendances inutiles. L’organisation doit consciemment concevoir et continuer à tester ces options.

Enregistrez une mesure de référence et un niveau souhaité pour chaque système critique. Mesurez ensuite des propriétés concrètes, telles que la part des parties connues de la chaîne, l’exportation des données testées, les clés gérées par le client, la récupération sans fournisseur, les interfaces ouvertes et le temps nécessaire pour changer.

Signalez également les dépendances restantes et les risques acceptés. Le progrès ne signifie pas que toute dépendance disparaît, mais que l’organisation gagne en perspicacité, en liberté de choix et en marge d’action démontrable.

Faites des demandes avant la conclusion du contrat. Renseignez-vous sur la juridiction, la propriété, l’emplacement des données, les sous-traitants, la gestion à distance, la gestion des clés, les normes ouvertes, les formats d’exportation, les droits d’audit, la continuité et la résiliation.

Enregistrez également la manière dont les preuves sont fournies et la manière dont les changements sont signalés. Un label de qualité ou une allégation marketing générale ne remplace pas un accord vérifiable. Utilisez les objectifs ECSF et les niveaux SEAL comme langage commun, le cas échéant.

Le stockage européen des données est pertinent, mais ne dit pas tout sur la juridiction, la propriété, la gestion, les clés d’accès, les sous-traitants et la dépendance technique.

Par conséquent, évaluez l’ensemble de la structure : quelles entités fournissent le service, quels droits peuvent être invoqués, qui peut effectuer des actions de gestion, qui gère les clés de chiffrement et quelles options de sortie sont disponibles ?

Oui. La dépendance peut affecter la disponibilité, l’intégrité et la confidentialité des informations. Pensez à l’échec ou à la résiliation d’un service, à un accès non désiré dans le cadre d’un système juridique différent ou à des changements que l’organisation ne peut pas contrôler elle-même.

C’est pourquoi la souveraineté appartient à la réglementation, à l’organisation et à la technologie : les trois parties interdépendantes décrites dans le livre sous le nom de ROT. Il ne s’agit pas d’une question politique distincte de celle de la sécurité de l’information.

Pas lorsque les exigences visent des risques gérables et s’appliquent de manière égale et vérifiable à tous les prestataires. Le protectionnisme protège avant tout sa propre industrie ; la politique de souveraineté protège le contrôle, la continuité, l’intégrité et la confidentialité.

La nationalité seule constitue donc un critère faible. La compétence, les accords exécutoires, l’isolement technique, l’ouverture et les options de sortie sont des aspects plus substantiels.

Non. Un nom ou un emplacement européen ne constitue pas une garantie complète. Un fournisseur européen peut également être racheté, faire faillite, s’appuyer fortement sur une technologie non européenne ou fournir de mauvaises garanties contractuelles.

Examinez les caractéristiques structurelles contrôlables : propriété et contrôle, lois applicables, gestion et accès aux clés, dépendances de la chaîne, normes ouvertes et plan de sortie exécutable.

Non. L’Open Source accorde des droits importants pour étudier un logiciel, le modifier et le faire maintenir par d’autres. Il peut donc soutenir la transparence, la remplaçabilité et le développement des connaissances.

Mais ces droits n’ont de valeur pratique que s’il existe une documentation, des personnes, une gestion, un financement, des mises à jour sécurisées et un accès à ses propres données. L’open source peut également dépendre d’un seul responsable, d’un service cloud fermé ou d’une infrastructure difficile à remplacer.

Non. La souveraineté dépend du contexte. Le niveau souhaité découle de la criticité du processus, de la sensibilité des données, des exigences légales, de l’appétit pour le risque et des alternatives disponibles.

Le niveau le plus élevé pour tous les systèmes peut être inutilement coûteux ou irréalisable. Un choix motivé par système est plus fort qu’un objectif général sans priorités.

Pas nécessaire. Les exigences d’interopérabilité, de transparence, de sécurité et de remplaçabilité peuvent en réalité stimuler l’innovation, car les nouveaux fournisseurs peuvent se connecter plus facilement et les clients sont moins enfermés.

Il existe de réels compromis en termes de coût, de vitesse et de fonctionnalité. Ceux-ci doivent être explicités. Le contraste entre « innovation ou souveraineté » est trop simple ; il s’agit d’innovation responsable dans le cadre d’un profil de risque choisi.

Commencez par la perspicacité. Créez un aperçu des processus critiques, des données, des systèmes, des fournisseurs, des sous-traitants, de l’accès à la direction, de la juridiction applicable et des options de sortie existantes.

Reliez ensuite les dépendances les plus importantes à la disponibilité, à l’intégrité et à la confidentialité. Ce n’est que lorsque l’on sait clairement ce qui est critique et de quoi cela dépend que l’on peut choisir un objectif et des mesures appropriés.

Le livre Souveraineté ! Comment ? discute de l’évolution historique, de la relation avec la sécurité de l’information, de l’ECSF, des arguments du débat et d’un chemin de croissance pratique pour les organisations.

Le message central est terre-à-terre : la souveraineté n’est pas un concept du tout ou rien ni un projet ponctuel. C’est l’organisation permanente de la vision, de l’orientation et de la marge d’action.

Le concept a pris forme en Europe à la fin du Moyen Âge et au début de l’époque moderne. Au XVIe siècle, Jean Bodin décrivait un pouvoir d’État suprême et permanent. La Paix de Westphalie de 1648 lie alors fortement la souveraineté aux États territoriaux et au principe de non-ingérence.

Plus tard, la légitimité est passée des monarques au peuple et les États ont commencé à exercer les pouvoirs conjointement, par exemple au sein de l’Union européenne. L’histoire montre que la souveraineté tourne toujours autour de la même question centrale : qui a finalement le dernier mot ?

Car la souveraineté n’est pas seulement une question de probabilité, mais aussi une question d’impact et de capacité d’action. Un événement peut être improbable et pourtant avoir des conséquences inacceptables sur un processus critique.

De plus, la dépendance peut déjà avoir une influence sans pour autant bloquer l’accès. La possibilité de sanctions, d’ordres juridiques ou de résiliation peut modifier la prise de décision et l’espace de négociation.

Les gouvernements, les entreprises et les organisations sociales sont devenus fortement dépendants d’un petit nombre de fournisseurs de cloud, de logiciels de bureautique, de communications et d’IA. Dans le même temps, la propriété, la législation, les sanctions, les rachats et les relations géopolitiques peuvent changer.

En conséquence, le contrôle formel peut entrer en conflit avec la dépendance réelle. La question urgente n’est pas seulement de savoir si un fournisseur est fiable aujourd’hui, mais aussi si l’organisation peut encore agir demain si les règles, l’accès ou les intérêts changent.

Faites la distinction entre les fonctions vraiment indispensables et les dépendances nées de l’habitude, du manque de connaissances ou d’anciens choix. Cartographiez concrètement les connexions, les formats de données, les licences, les processus et les compétences.

Ensuite, pratiquez l’exportation, la récupération et les alternatives avant qu’il n’y ait une crise. Un plan de sortie qui n’a jamais été testé offre peu de certitude. Parfois, une migration complète n’est pas réalisable dans l’immédiat, mais les formats ouverts, l’architecture modulaire et une deuxième voie de mise en œuvre peuvent déjà améliorer la situation.

Il est alors judicieux d’adopter une approche progressive. Déterminez d’abord pour quels processus la dépendance présente le plus grand risque et quelles fonctions sont réellement nécessaires. Améliorez ensuite les contrats, l’architecture et la portabilité, puis migrez là où une alternative appropriée est disponible.

Le fait qu’une alternative soit moins mature aujourd’hui est un argument de rythme et d’exécution, et non automatiquement une raison pour ignorer le risque. Le livre discute donc d’un chemin de croissance plutôt que d’une grande transition.

La souveraineté numérique est la mesure dans laquelle un gouvernement ou une organisation maintient réellement le contrôle de ses fonctions, données et dépendances numériques. Les droits formels et les options réelles d’action comptent.

Les questions spécifiques sont les suivantes : où se trouvent les données, qui peut y accéder, quelle loi s’applique, qui gère les clés, le service peut-il continuer en cas de conflit et est-il raisonnablement possible de changer de service ?

L’ECSF est un cadre européen d’évaluation de la souveraineté du cloud. Il aide les organisations publiques à décrire les risques de souveraineté, à fixer les exigences d’achat et à comparer la situation actuelle et souhaitée.

Le cadre déplace le discours des affirmations générales, telles que « européenne » ou « souveraine », vers des propriétés testables. Il examine, entre autres, la juridiction, les données, les opérations, les chaînes, la technologie, la sécurité et la durabilité.

La souveraineté est une question d’autorité et de direction : qui a le dernier mot et porte la responsabilité ? L’autonomie concerne la capacité pratique d’agir de manière indépendante et d’utiliser des alternatives.

Une organisation peut être formellement autorisée mais disposer de peu d’autonomie si elle ne peut pas techniquement changer de système ou si seul un fournisseur peut gérer le système. La souveraineté sans marge d’action suffisante reste alors largement sur le papier.

La souveraineté est le pouvoir de prendre des décisions contraignantes et d’en assumer la responsabilité. Dans les environnements numériques, la principale question est de savoir qui décide en fin de compte des données, des infrastructures, de la technologie et de l’accès.

Cela ne signifie pas qu’une organisation doit tout construire ou tout gérer elle-même. Cependant, elle doit être capable de faire des choix conscients, de faire respecter les accords et d’agir lorsque les circonstances changent. Le livre Souveraineté ! Comment ? Cela constitue une question administrative pratique.

Les niveaux SEAL décrivent des niveaux croissants de souveraineté du cloud. Le niveau 0 est un cloud public standard sans mesures de souveraineté supplémentaires ; Le niveau 4 représente un environnement hautement souverain avec une autonomie démontrable.

Les niveaux ne constituent pas une note pour un fournisseur. Ils aident une organisation à déterminer un niveau actuel (IST) et un niveau souhaité (SOLL) appropriés par application. Un système critique peut donc se voir attribuer une vocation plus élevée qu’un service public ou facilement remplaçable.

L’open source peut être utile car une organisation peut étudier un logiciel, le faire vérifier, ajuster et maintenir par un tiers. Les droits ouverts soutiennent donc la transparence, la remplaçabilité et le développement de ses propres connaissances.

L’open source n’est pas une garantie automatique de souveraineté. La valeur pratique dépend également de la documentation, des personnes, de la gestion, du financement, des mises à jour sécurisées, des formats de données ouverts et de l’infrastructure sur laquelle le logiciel s’exécute.

L’ECSF distingue huit objectifs interdépendants : la souveraineté stratégique ; souveraineté juridique et juridictionnelle ; souveraineté des données et de l’IA ; souveraineté opérationnelle; la souveraineté en chaîne ; souveraineté technologique; la sécurité et la souveraineté en matière de conformité ; et la souveraineté en matière de durabilité.

Cette classification évite qu’une caractéristique, telle que l’emplacement d’un centre de données, soit utilisée à tort comme preuve d’une pleine souveraineté. Un service peut marquer fort sur un but et faible sur un autre.

OciDeck prend en charge la souveraineté de l’information et de la technologie en permettant au contenu de la présentation de rester dans un format Markdown lisible. Les formats ouverts rendent le contenu plus contrôlable, réutilisable et portable que lorsqu’il est contenu uniquement dans un format d’application fermé.

Le traitement local, l’exportation HTML hors ligne et les fonctionnalités de partage et de confidentialité ciblées peuvent réduire la dépendance à l’égard des services de présentation tiers et la distribution accidentelle. La souveraineté ultime dépend également du stockage, de la gestion et des choix des utilisateurs. En savoir plus sur OciDeck.

OpenKAT contribue principalement à la souveraineté opérationnelle, technologique et sécuritaire. Il rassemble des objets numériques, des relations, des observations et des résultats afin qu’une organisation puisse mieux comprendre et surveiller son propre environnement et ses risques.

Étant donné qu’OpenKAT est open source et peut être exécuté lui-même, une organisation peut surveiller son fonctionnement et choisir qui gère le système. OpenKAT n’assure pas une souveraineté totale : une gestion minutieuse, le périmètre, la protection des données, la connaissance et le suivi restent nécessaires. En savoir plus sur OuvrirKAT.

Une approche utile est la suivante : 1. inventorier les processus, les données et les dépendances ; 2. déterminer le niveau de souveraineté souhaité par système ; 3. améliorer les achats, les contrats, l’architecture, les connaissances et les alternatives ; 4. Vérifiez périodiquement si les mesures fonctionnent toujours et effectuez les ajustements.

Traitez cela comme un cycle. Fournisseurs, propriété, législation et changement technologique. Une évaluation ponctuelle devient donc vite obsolète.

Le conseil d’administration est en dernier ressort responsable de l’orientation, de l’appétit pour le risque et de l’acceptation du risque résiduel. Les achats, les affaires juridiques, la sécurité de l’information, l’architecture, la confidentialité, la gestion et le propriétaire du processus constituent chacun une partie nécessaire du tableau.

Parce que les choix ont souvent des conséquences à long terme, le livre qualifie la souveraineté de « chef-sache ». Le sujet ne peut se limiter uniquement à la technologie ou à la gestion des contrats.

L’open source est une forme de licence. Le créateur ou le titulaire des droits autorise au préalable les autres à utiliser, étudier, copier, distribuer et adapter l’œuvre.

Le droit de procéder à des ajustements est essentiel. Si la modification n’est pas autorisée, ce n’est pas open source.

Le noyau est légal. L’open source concerne la manière dont le droit d’auteur est exercé : via une licence qui donne de larges droits d’utilisation.

Il peut y avoir des idées techniques et sociales derrière cela, mais sans une licence appropriée, quelque chose n’est pas open source.

Cela signifie que le titulaire des droits donne l’autorisation d’utiliser, d’étudier, de copier, de distribuer et de modifier le code source via une licence open source.

Le logiciel reste protégé par le droit d’auteur. La licence détermine les droits et conditions applicables.

L’open source et les logiciels libres concernent les droits : utiliser, étudier, partager et adapter. Freeware signifie généralement simplement que quelque chose est gratuit à utiliser.

Le domaine public signifie qu’il n’y a plus de restriction de droit d’auteur ou que le titulaire des droits y a renoncé dans la mesure où la loi le permet. C’est différent de l’open source.

Non. L’Open Source donne de nombreux droits, mais toujours dans le cadre des termes de la licence.

Ces conditions peuvent par exemple concerner l’attribution, la conservation des textes de licence ou le partage des modifications sous une même licence.

Le créateur ou l’ayant droit reste propriétaire du droit d’auteur, sauf si ce droit a été transféré.

Open source ne signifie pas qu’il n’y a pas de propriétaire. Cela signifie que le propriétaire accorde des droits étendus à autrui par le biais d’une licence.

Oui. L’open source n’exclut pas une utilisation commerciale. Une entreprise peut utiliser l’open source, vendre des services open source ou proposer elle-même des logiciels open source.

Le modèle de prix et de revenus est distinct des droits open source.

L’open source concerne les droits sur une œuvre, généralement un logiciel. Les normes ouvertes concernent les accords, les spécifications ou les protocoles qui peuvent être utilisés par plusieurs parties.

Ils peuvent se renforcer mutuellement, mais ce sont des choses différentes.

Une licence open source est une autorisation préalable donnée par le titulaire des droits. Il indique ce que d’autres peuvent faire avec le travail et quelles conditions s’appliquent.

Sans une telle licence, le droit d’auteur normal continue de s’appliquer et la réutilisation n’est généralement pas autorisée.

Parce que le droit d’auteur naît automatiquement. En principe, quiconque crée un texte, un design ou un logiciel en a les droits.

Une licence indique clairement quelle autorisation les autres reçoivent. Avec l’open source, cette autorisation est large et organisée à l’avance.

Le code est alors visible, mais pas automatiquement libre d’utilisation. La visibilité n’est pas le consentement.

Sans licence, une autre personne ne peut généralement pas copier, distribuer ou modifier le code, sauf exceptions légales limitées.

Les licences permissives offrent une grande liberté et imposent généralement des conditions limitées, telles que l’attribution et la conservation du texte de la licence.

Les licences Copyleft accordent également des droits étendus, mais peuvent exiger que les œuvres dérivées soient distribuées sous la même licence ou sous une licence similaire.

Le copyleft est un principe de licence où la liberté doit être transmise. Quiconque distribue l’œuvre, souvent sous une forme adaptée, doit accorder aux autres les mêmes droits.

Il ne s’agit donc pas d’une renonciation aux droits, mais plutôt d’une manière active d’utiliser les droits pour maintenir l’ouverture.

Cela dépend de la licence et de ce que vous faites. Certaines licences copyleft peuvent nécessiter une divulgation si vous distribuez un logiciel modifié.

Seule l’utilisation interne n’entraîne généralement pas automatiquement une telle obligation, mais le résultat précis dépend de la situation et de la licence.

Oui, de nombreuses licences open source autorisent une utilisation commerciale. C’est précisément une caractéristique de l’open source.

Vous devez cependant respecter les conditions du permis. Pensez à mentionner votre nom, les textes de licence ou les conditions de distribution.

Oui, l’open source devrait permettre la personnalisation. Les ventes sont également possibles, à condition que les conditions de licence soient respectées.

Certaines licences exigent que vous fournissiez ou rendiez disponible le code source modifié lorsque vous distribuez l’œuvre modifiée.

Ce sont des moyens de garder le créateur d’origine et la licence visibles. Attribution signifie généralement attribution. Un fichier de notices contient des mentions légales. Un en-tête de licence se trouve souvent en haut d’un fichier.

Ces obligations garantissent que les droits et l’origine restent reconnaissables.

Une clause de brevet garantit que les utilisateurs reçoivent également l’autorisation des contributeurs pour les brevets pertinents sous certaines conditions.

Cela peut être important car les logiciels peuvent être affectés non seulement par le droit d’auteur, mais parfois aussi par les droits de brevet.

Le principal risque est que les conditions de licence ne soient pas respectées. Vous utilisez peut-être alors l’œuvre sans autorisation valide.

Cela peut entraîner des obligations de réparation, des réclamations juridiques, des atteintes à la réputation ou des problèmes de vente, d’appel d’offres ou d’audit.

La conformité open source signifie qu’une organisation sait quel open source elle utilise, quelles licences l’accompagnent et quelles obligations s’appliquent.

Il s’agit principalement d’une gestion juridique et organisationnelle normale : enregistrer, vérifier, se conformer et pouvoir expliquer ce qui a été utilisé.

Non, pas à cause de la nature open source. La sécurité dépend de la conception, de la maintenance, du contrôle, de l’utilisation et de la surveillance des vulnérabilités.

L’ouverture permet le contrôle, mais n’est pas une garantie automatique de sécurité.

Non. Tout le monde peut souvent faire des propositions, mais cela ne veut pas dire que tout le monde peut simplement apporter des changements.

Pour les projets sérieux, les administrateurs évaluent quelles contributions sont incluses. La fiabilité dépend de la gouvernance et de la maintenance, et pas seulement du type de licence.

Non. Le soutien peut être volontaire, communautaire ou commercial. De nombreuses entreprises proposent un support payant pour l’open source.

La licence détermine les droits sur l’œuvre ; le support est un service distinct.

Non. L’Open Source est une question de droits d’utilisation, pas de prix.

Un produit open source peut être téléchargé gratuitement, mais le support, l’hébergement, la certification, la formation ou la personnalisation peuvent être payants.

Non, la gratuité est une question de prix. La gratuité est une question de droits.

Un produit gratuit peut être strictement fermé. Un produit open source donne des droits d’utilisation, d’étude, de partage et de modification.

Non. L’open source peut être créé par des bénévoles, mais aussi par des entreprises, des gouvernements, des universités et des fondations.

La licence ne dit rien sur le professionnalisme. Vous devez évaluer cela en fonction de la qualité, de la gestion et du contexte.

Non. L’Open Source peut être très professionnel et les logiciels commerciaux peuvent être mal entretenus. L’inverse est également possible.

Le professionnalisme est évident dans la maintenance, la documentation, la gouvernance, la qualité et les accords, et non seulement dans les licences ouvertes ou fermées.

L’ouverture signifie que tout le monde peut regarder, y compris les parties malveillantes. Mais cela signifie également que le contrôle par les utilisateurs, les chercheurs et les fournisseurs est possible.

La sécurité ne vient pas uniquement du secret. Cela nécessite un entretien, une réponse et une utilisation prudente.

Non. Les droits légaux s’appliquent à tout le monde : utilisateurs, administrateurs, acheteurs, avocats, auditeurs et décideurs politiques.

Les développeurs travaillent souvent avec le code, mais les organisations bénéficient également de la transparence, de la liberté de choix et de la possibilité d’audit.

C’est peut-être un compromis, mais ce n’est pas automatiquement un inconvénient. L’open source consiste à déterminer consciemment quelles parties vous souhaitez partager et dans quelles conditions.

Parfois, le partage ouvert est stratégiquement utile, par exemple pour promouvoir la collaboration, la confiance ou la standardisation.

Cela varie selon le projet. Le contrôle peut provenir des responsables, des utilisateurs, des chercheurs en sécurité, des audits, des analyses automatiques et des organisations qui déploient le logiciel.

L’open source rend ce contrôle possible, mais ne l’organise pas à lui seul.

Cela dépend de la situation. Les administrateurs du projet peuvent créer une mise à jour, mais l’utilisateur ou l’organisation doit également appliquer cette mise à jour.

L’open source ne change rien au fait que quiconque utilise un logiciel reste responsable d’une gestion minutieuse.

Cela varie énormément. Les projets actifs peuvent réagir rapidement ; n’abandonnez pas les projets. Il en va de même pour les logiciels fermés.

Par conséquent, n’examinez pas seulement la licence, mais également la maintenance, le processus de reporting et les pratiques de publication.

Les risques liés à la chaîne d’approvisionnement surviennent lorsque vous dépendez de pièces provenant de tiers. Si une telle pièce est vulnérable, malveillante ou mal entretenue, cela peut avoir des conséquences sur votre propre produit.

Ce risque n’est pas exclusif à l’open source, mais l’open source rend souvent les dépendances plus visibles.

Les dépendances sont des parties sur lesquelles un produit est basé. Avec les logiciels, il s’agit souvent de bibliothèques ou de packages tiers.

Ils sont importants car les droits, les vulnérabilités et la maintenance de ces pièces influencent également votre propre utilisation.

Examinez la licence, la maintenance, la documentation, la manière dont les modifications sont examinées et la manière dont les alertes de sécurité sont traitées.

La fiabilité est une combinaison de clarté juridique, de qualité et de gestion.

Les signaux sains sont des informations claires sur les licences, des mises à jour récentes, une documentation compréhensible, un processus de reporting actif et une prise de décision visible.

Il est également utile que plusieurs personnes ou organisations contribuent, afin que le projet ne dépende pas entièrement d’une seule personne.

Recherchez les anciennes versions, les notifications sans réponse, les informations de licence manquantes, les responsables peu clairs ou l’absence de réponse aux problèmes de sécurité.

Ce sont des risques de projet. Ils apparaissent dans les logiciels ouverts et fermés, mais dans l’open source, ils sont souvent plus visibles.

Lors d’un audit de sécurité, quelqu’un évalue spécifiquement s’il existe des vulnérabilités ou des points faibles. Avec l’open source, le code source peut être examiné directement.

Un audit est un instantané. L’entretien et le suivi continueront alors d’être nécessaires.

Un SBOM est une nomenclature logicielle : un aperçu des composants logiciels utilisés.

Une telle vue d’ensemble permet de gérer les licences, les vulnérabilités et les dépendances. Il est particulièrement utile pour les organisations qui doivent pouvoir expliquer ce qu’elles utilisent.

Un projet open source est créé lorsqu’un titulaire de droits publie une œuvre sous une licence open source. Cela inclut souvent une documentation, un lieu de contribution et un mode de prise de décision.

La licence constitue la base légale ; la communauté et la méthode de travail déterminent la façon dont le projet continue de croître.

Ceci est généralement effectué par les responsables ou les administrateurs du projet. Ils évaluent si une contribution est conforme à la qualité, à l’orientation et aux accords du projet.

Open source ne signifie pas que chaque modification fait automatiquement partie du projet officiel.

Un mainteneur est quelqu’un qui gère un projet. Cette personne ou ce groupe examine les contributions, publie des versions, surveille les orientations et maintient la documentation ou les processus.

En open source, ce rôle est important car les droits sont larges, mais la collaboration nécessite encore de l’organisation.

Un contributeur est quelqu’un qui contribue à un projet. Il peut s’agir de problèmes de code, mais aussi de documentation, de traduction, de test, de conception, d’explication ou de reporting.

Les contributions open source vont donc plus loin que la programmation.

Un fork est votre propre copie d’un projet sur lequel quelqu’un peut continuer à travailler de manière indépendante. C’est possible car l’open source permet la modification et la distribution.

Parfois, une amélioration se reflète plus tard dans le projet original. Parfois, une fourchette grandit dans sa propre direction.

Il s’agit d’une proposition visant à inclure un changement dans un projet. L’administrateur peut examiner, discuter, ajuster ou rejeter la modification.

C’est un moyen pratique d’organiser la collaboration autour de l’open source.

La gouvernance communautaire concerne les accords avec lesquels un projet prend des décisions. Réfléchissez à qui peut participer à la prise de décision, à la manière dont les conflits sont résolus et à la manière dont les nouveaux administrateurs sont nommés.

La licence donne des droits ; la gouvernance régule la coopération.

Dans les projets menés par la communauté, le contrôle appartient principalement à une communauté de participants. Dans les projets menés par l’entreprise, celle-ci joue souvent un rôle majeur ou décisif.

Les deux formes peuvent bien fonctionner, à condition qu’il soit clair qui décide et dans quelles conditions.

Cela dépend de la gouvernance. Certains projets disposent de règles de décision, de codes de conduite ou de fondations claires. D’autres projets sont plus informels.

De bons accords sont importants car l’ouverture des droits ne signifie pas automatiquement que tout le monde est d’accord.

Les projets s’arrêtent lorsque les responsables manquent de temps, que le financement manque, que le besoin disparaît ou qu’une meilleure solution apparaît.

Ce n’est pas propre à l’open source. La différence est qu’avec l’open source, d’autres peuvent parfois continuer avec un fork.

Les entreprises ne gagnent pas nécessairement de l’argent en vendant exclusivement le code, mais grâce aux services qui l’entourent. Pensez à l’hébergement, au support, à la mise en œuvre, à la gestion, à la formation, à la certification ou à la personnalisation.

La licence ouverte et le modèle économique sont deux niveaux différents.

Les modèles courants incluent le support payant, l’hébergement géré, le conseil, la certification, la formation, la double licence et le noyau ouvert.

Le point de départ est souvent le suivant : les droits fondamentaux sont ouverts, mais la commodité, la sécurité ou des services supplémentaires peuvent être payants.

Open Core signifie que le cœur d’un produit est open source, tandis que certaines fonctionnalités supplémentaires sont fermées ou payantes.

Cela peut fonctionner, mais cela nécessite une communication claire. Les utilisateurs doivent savoir quelle partie est ouverte et laquelle ne l’est pas.

La double licence signifie que la même œuvre est disponible sous deux licences différentes. Par exemple, une licence open source et une licence commerciale.

Cela peut donner le choix aux organisations, mais n’est possible que si le titulaire des droits a le droit de proposer les deux licences.

L’hébergement géré ou SaaS signifie que quelqu’un propose un logiciel open source en tant que service. L’utilisateur n’a alors pas besoin d’installer et de gérer lui-même le logiciel.

Le logiciel peut être open source, tandis que le service qui l’entoure est payant.

Les entreprises peuvent le faire pour accroître la confiance, stimuler la collaboration, établir une norme ou accélérer l’adoption.

L’open source peut également contribuer à réduire la dépendance à l’égard d’un seul fournisseur et à créer un écosystème.

Parce que d’autres sont autorisés à s’appuyer sur des travaux existants. Ils n’ont pas besoin de recommencer et peuvent partager leurs améliorations.

La licence rend cette collaboration légalement possible.

L’open source peut réduire la dépendance à l’égard d’un seul fournisseur car les utilisateurs ont le droit d’étudier le logiciel, de le modifier et de le faire gérer ailleurs.

Cela ne signifie pas que le changement soit toujours facile, mais la base juridique est moins fermée.

L’open source est intéressant lorsque la collaboration, la transparence, la vérifiabilité, la réutilisation ou l’indépendance sont importantes.

Elle est particulièrement forte dans les infrastructures partagées, les valeurs publiques et les situations où la confiance exige plus qu’une promesse d’un fournisseur.

L’open source est moins adapté lorsque l’ayant droit souhaite limiter la distribution, l’accès ou la modification. Il s’agit d’un choix stratégique en matière de contrôle.

Cela est également moins approprié si une organisation souhaite accorder des droits sans être prête à consigner clairement les conditions et la gestion des licences.

Les startups peuvent s’appuyer plus rapidement sur des composants existants et gagner plus facilement la confiance grâce à l’ouverture. Ils peuvent également développer une communauté ou un marché autour d’un projet ouvert.

Ils doivent être conscients des licences, du positionnement et de leur modèle de revenus.

Pour les gouvernements, l’open source peut contribuer à la transparence, à l’auditabilité, à la réutilisation et à une moindre dépendance à l’égard d’un seul fournisseur.

Cela cadre bien avec la responsabilité publique, à condition que la gestion, la sécurité et le respect de la loi soient correctement organisés.

L’éducation peut utiliser l’open source pour apprendre à partir d’exemples réels, partager du matériel et permettre aux étudiants de contribuer aux projets existants.

Parce que l’ajustement est autorisé, le matériel pédagogique ou les logiciels peuvent être mieux alignés sur la pratique éducative.

L’open source peut être utile car les organisations ne dépendent pas entièrement de connaissances fermées ou d’un seul fournisseur. Ils peuvent faire vérifier le fonctionnement de quelque chose et le faire ajuster.

La souveraineté nécessite plus que l’open source, mais les droits ouverts constituent un élément de base important.

L’open source rend visible dans quelles conditions une œuvre peut être utilisée et, dans le cas d’un logiciel, à quoi ressemble le code source.

Cela facilite le contrôle et l’explication. La transparence n’existe réellement que lorsque la documentation et la gouvernance sont également claires.

Étant donné que d’autres sont autorisés à utiliser et à adapter des œuvres existantes, tout le monde n’est pas obligé de recréer la même chose.

Cela peut réduire le gaspillage et partager la maintenance, en particulier lorsque plusieurs parties ont le même problème.

L’open source montre comment fonctionne une organisation, quelle qualité elle recherche et ce qu’elle représente. Les gens peuvent facilement contribuer ou savoir ce qui se passe.

Cela peut être attrayant pour les professionnels qui apprécient l’ouverture et le savoir-faire.

Les concurrents peuvent collaborer sur les pièces dont tout le monde a besoin, sans que ces pièces soient nécessairement le produit distinctif.

La licence clarifie à l’avance les droits, de sorte que la collaboration dépend moins d’accords séparés.

Les infrastructures publiques nécessitent confiance, continuité et vérifiabilité. L’open source peut aider car la base n’est pas entièrement à huis clos.

Cela rend plus possible un contrôle indépendant et une maintenance conjointe.

Dans ces domaines, l’open source peut contribuer à la vérifiabilité, à la réutilisation et à la recherche indépendante.

Dans le même temps, la bonne gouvernance, la gestion des données, la sécurité et l’évaluation juridique restent nécessaires. L’open source est une exigence fondamentale pour certaines formes de contrôle, et non une solution totale.

Commencez par la licence : l’utilisation que vous envisagez est-elle autorisée ? Regardez ensuite la maintenance, la documentation, la qualité et les dépendances.

Un forfait populaire ne convient pas automatiquement. Le choix doit correspondre à l’objectif, au risque et à la gestion.

Vérifiez la licence, l’origine, l’état de la maintenance, les vulnérabilités et la nécessité. Demandez également si la pièce est vraiment nécessaire.

Chaque dépendance ajoute des droits, des obligations et de la gestion.

Enregistrez quels composants sont utilisés, quelle version, quelle licence et dans quoi le composant est inclus.

Assurez-vous également de préciser clairement qui est responsable des mises à jour et du respect des conditions.

Utilisez une combinaison d’outils d’enregistrement, de vérification périodique et d’analyse des dépendances.

Plus important encore : convenez de qui examinera les notifications et qui décidera des mises à jour ou des remplacements.

Il existe de nombreux outils qui cartographient les dépendances, les licences et les vulnérabilités. Les exemples incluent les scanners dans les plates-formes de développement, les gestionnaires de packages et les outils de conformité spécialisés.

L’outil n’est qu’un outil. L’organisation doit encore faire des choix et organiser le suivi.

Veuillez d’abord lire les instructions de contribution et la licence. Décrivez clairement ce que vous souhaitez améliorer et pourquoi.

Une bonne contribution peut être du code, mais aussi de la documentation, des tests, une traduction ou un problème clairement décrit.

Cela est logique si vous souhaitez que d’autres puissent utiliser, surveiller, partager et modifier le travail.

Faites ce choix consciemment : déterminez l’objectif, la licence, la maintenance, la gouvernance et ce que vous attendez ou non des contributions.

Décidez d’abord de ce que vous souhaitez autoriser et protéger. Si vous souhaitez une large réutilisabilité, envisagez les licences permissives. Si vous voulez que la liberté soit transmise, regardez le copyleft.

Utilisez de préférence des licences existantes et connues au lieu de rédiger vous-même le texte.

Fournissez une documentation claire, une manière conviviale de poser des questions, une prise de décision claire et des attentes réalistes.

Une communauté ne se crée pas simplement en mettant du code en ligne. Cela demande de l’attention, de la confiance et de l’entretien.

Divisez les droits et les responsabilités. Documentez les processus, rendez les versions portables et accordez à plusieurs personnes de confiance des droits de gestion.

Cela augmente la continuité et rend le projet moins vulnérable.

Un bureau de programme Open Source, souvent appelé OSPO, est une équipe ou une fonction qui organise l’utilisation et les contributions open source au sein d’une organisation.

Il facilite les politiques, les licences, la collaboration, les communautés et la publication responsable.

Au minimum, des politiques sont nécessaires pour l’utilisation, la contribution, la publication, le contrôle des licences et le suivi de la sécurité.

La politique doit être pratique : les gens doivent savoir ce qui est autorisé, quand demander conseil et qui décide.

Expliquez dans un langage simple ce que signifient les droits d’auteur, les licences et les obligations. Utilisez des exemples tirés de votre propre travail.

La formation ne doit pas seulement être juridique, mais aussi pratique : que s’inscrire, que vérifier et où demander de l’aide ?

Tout dépend du choix. Le juridique examine les droits et les obligations. La sécurité examine les vulnérabilités et la gestion. L’ingénierie examine la qualité et l’application. L’approvisionnement examine les contrats et les fournisseurs.

L’open source affecte souvent plusieurs responsabilités en même temps.

Assurez-vous qu’il soit clair quelles pièces ont été utilisées, quelles licences s’appliquent, quels contrôles ont été effectués et quelles décisions ont été prises.

Auditable signifie principalement : être capable d’expliquer ensuite ce qui s’est passé et pourquoi.

Incluez consciemment l’open source dans les exigences, les critères d’évaluation et les conditions contractuelles. Ne posez pas seulement des questions sur un produit, mais aussi sur les droits, la portabilité et la gestion.

De cette façon, vous évitez que l’ouverture ne reste qu’un souhait et n’aboutisse pas à une mission.

Considérez le support comme un complément aux droits open source. Le contrat peut contenir des accords sur les délais de réponse, les mises à jour, la responsabilité, l’hébergement ou la gestion.

Le logiciel peut être ouvert, tandis que le support est professionnel et payant.

Ne regardez pas seulement les coûts de licence. Inclut également la gestion, le support, la formation, l’intégration, la migration, la conformité et la maintenance.

L’open source peut être moins cher, mais la véritable valeur réside souvent dans le contrôle, la flexibilité et moins de dépendance.

Considérez l’open source comme faisant partie de la gestion normale des risques. Examinez les licences, la maintenance, la sécurité, les dépendances et la continuité.

Le risque n’est pas que quelque chose soit open source, mais que son utilisation se fasse inconsciemment ou sans surveillance.

Ne vous contentez pas de mesurer les coûts économisés. Pensez également à la réutilisation, à la rapidité, à la transparence, aux dépendances évitées, à la collaboration et à la qualité du contrôle.

Certaines valeurs sont financières, d’autres sont liées à l’autonomie et à la confiance.

Non. L’Open Source offre d’importantes libertés, mais ne dit automatiquement rien sur tous les choix éthiques en matière d’utilisation, d’impact ou de gouvernance.

L’ouverture peut contribuer à faciliter la discussion, le contrôle et la responsabilisation.

Pas complètement. Les licences open source autorisent une large utilisation et ne limitent généralement pas l’utilisation de l’œuvre par quelqu’un.

Quiconque veut limiter les abus finit rapidement par dépasser l’open source classique et doit réfléchir à d’autres moyens juridiques ou organisationnels.

Les licences open source classiques ne limitent pas les finalités d’utilisation. Ils donnent des droits à chacun, même si le créateur considère certaines applications comme indésirables.

Il existe des licences avec des restrictions d’utilisation éthiques, mais elles ne sont généralement pas considérées comme open source au sens strict.

L’open source donne aux autres le contrôle de leur propre utilisation : ils peuvent étudier, s’adapter et partager. Le créateur original renonce donc à un certain contrôle exclusif sur la distribution et la modification.

Ce n’est pas une erreur, mais c’est exactement le choix qui rend l’open source spécial.

L’open source peut soutenir des valeurs publiques telles que la transparence, l’auditabilité, la réutilisation et l’indépendance.

Mais les valeurs publiques exigent également de la bonne gouvernance, de l’accessibilité, de la sécurité, du financement et de la responsabilité.

Cela varie considérablement selon le projet. Certaines communautés sont ouvertes et serviables, d’autres sont difficiles d’accès ou dépendent de réseaux informels.

L’inclusion nécessite une attention active au langage, au comportement, à la documentation, à la prise de décision et à une participation sécuritaire.

C’est une question importante. Une grande partie de l’infrastructure numérique est largement utilisée, mais pas toujours largement financée.

L’open source rend l’utilisation possible, mais la maintenance nécessite du temps, de l’argent et de la responsabilité de la part des parties qui en dépendent.

L’open source peut répandre le pouvoir parce que les utilisateurs ont plus de droits que le simple fait d’acheter ce que propose un fournisseur. Ils peuvent le faire vérifier, ajuster ou changer.

Cela renforce l’autonomie, mais seulement s’il existe les connaissances, les capacités et la gouvernance nécessaires pour utiliser ces droits.

Une prévention complète n’est généralement pas possible dans le cadre de l’open source classique. Cependant, les projets peuvent opter pour des licences appropriées, une gouvernance, des accords commerciaux et une culture dans laquelle les contributions sont normales.

Les utilisateurs peuvent également assumer leurs responsabilités en restituant de la maintenance, de l’argent ou des connaissances.

L’open source reste important pour l’infrastructure numérique, le gouvernement, l’éducation, le cloud, l’IA et la sécurité. L’essentiel reste juridique : donner le droit d’utiliser, d’étudier, de partager et d’adapter.

Le grand défi est la gestion durable : garantir que les projets ouverts sont non seulement utilisés, mais également entretenus et gérés de manière responsable.

MIAUW signifie Méthodologie de recherche sur la sécurité de l’information avec valeur d’audit. Il s’agit d’un moyen de mener des recherches de sécurité, telles qu’un test d’intrusion, de manière structurée et vérifiable.

L’objectif est qu’une organisation non seulement reçoive un rapport, mais puisse également mieux démontrer ce qui a été étudié, comment cela a été fait et quelles conclusions en découlent.

En savoir plus sur MIAUW.

De nombreuses enquêtes de sécurité produisent des résultats utiles, mais sont difficiles à évaluer par la suite. Parfois, on ne sait pas exactement ce qui entre dans le champ d’application, quelles étapes ont été réalisées ou quelles preuves étayent une conclusion.

MIAUW permet de mieux enregistrer ces composants avant et pendant la recherche. Cela rend la recherche plus utile pour le recouvrement, la responsabilité et les audits.

En savoir plus sur MIAUW et dans Que signifie la valeur d’audit ?.

Non. Un pen test est une forme de recherche de sécurité. MIAUW est une méthodologie visant à mieux structurer, enregistrer et rendre ces recherches plus contrôlables.

Un pen test peut donc être effectué selon MIAUW, mais MIAUW est plus large que la simple réalisation de tests techniques.

Lisez également Qu’est-ce qu’un test d’écriture ? et MIAUW.

La valeur d’audit signifie qu’une enquête peut être correctement évaluée par la suite. Un auditeur ou autre évaluateur doit être en mesure de voir ce qui a été convenu, ce qui a été testé, quelles preuves existent et comment les conclusions ont été tirées.

Cela rend une enquête utile non seulement pour la technologie, mais également pour la gouvernance, la conformité et la responsabilité.

Pour en savoir plus, consultez MIAUW et Qu’est-ce qu’un rapport d’audit chez MIAUW ?.

MIAUW est destiné aux clients, aux testeurs d’intrusion, aux auditeurs, aux spécialistes de la conformité et aux administrateurs.

Le client acquiert plus de contrôle sur la recherche. Le chercheur reçoit une structure claire. L’auditeur reçoit des informations plus vérifiables. Les administrateurs acquièrent plus de certitude sur ce que dit et ne dit pas un rapport.

En savoir plus sur MIAUW.

Non. Aucune méthodologie ne peut garantir la sécurité d’un système.

MIAUW aide à mieux mener des recherches sur la sécurité, à mieux les documenter et à mieux les utiliser à des fins d’amélioration. Cela augmente donc la qualité et l’utilité de la recherche, mais ne remplace pas une bonne gestion de la sécurité.

Lisez également Qu’est-ce qui est au cœur d’une étude MIAUW ?.

L’accent est mis sur des accords clairs, un champ d’application clair, des preuves imitables, des résultats reproductibles et des rapports utiles pour différents groupes cibles.

Une équipe technique veut des détails pour résoudre des problèmes. La direction veut savoir ce que signifie le risque. Un auditeur veut pouvoir évaluer si l’enquête a été menée avec soin.

En savoir plus sur MIAUW.

La portée signifie : ce qui fait et ne fait pas partie de la recherche. Pensez aux systèmes, domaines, applications, comptes, réseaux, périodes et questions de recherche.

Un champ d’application clair évite les malentendus. Sans champ d’application, il est difficile de dire a posteriori si quelque chose a été délibérément laissé hors de vue ou accidentellement n’a pas été examiné.

Voir également Comment OpenKAT gère-t-il la portée et les autorisations ?.

Les preuves rendent les résultats vérifiables. Un rapport ne doit pas seulement dire que quelque chose ne va pas, mais aussi montrer sur quoi se fonde cette conclusion.

Les preuves peuvent inclure des journaux, des captures d’écran, des sorties de commandes, des données de configuration ou d’autres enregistrements. Bien entendu, les informations sensibles doivent être traitées avec précaution.

Lisez également Que signifie la sécurité fondée sur des preuves ?.

Un résultat est un problème, un risque ou un point d’attention identifié lors de la recherche.

Un bon résultat décrit ce qui a été découvert, pourquoi c’est important, quelles preuves sont impliquées, quel pourrait être l’impact et quelle mesure contribue à réduire ou à résoudre le problème.

Lisez également Quelle est la différence entre un risque et une vulnérabilité ?.

Une vulnérabilité est un point faible. Un risque concerne ce que cette faiblesse peut signifier pour l’organisation.

Une vulnérabilité dans un système de test sans données sensibles présente souvent un risque différent de la même vulnérabilité dans un système public contenant des données personnelles. Le contexte est donc important.

Lisez également Qu’est-ce qu’une constatation ?.

Non. Les grandes organisations ont souvent des exigences plus formelles en matière d’audit et de conformité, mais les petites organisations bénéficient également d’accords clairs, de meilleures preuves et de rapports utiles.

MIAUW peut réellement contribuer à rendre la recherche sur la sécurité plus compréhensible et transférable.

En savoir plus sur MIAUW.

La déclaration d’un auditeur peut contribuer à démontrer qu’une enquête a été menée conformément aux accords, sans que tous les détails techniques doivent être largement partagés.

Ceci est utile lorsqu’un rapport complet est trop sensible pour être diffusé à grande échelle, mais qu’une organisation doit démontrer que des recherches sérieuses et vérifiables ont été menées.

Lisez également Si je fais un pentest avec MIAUW, dois-je le rendre public ?.

Un pen test, ou test d’intrusion complet, est une enquête de sécurité contrôlée. Les chercheurs tentent de trouver les vulnérabilités avant les parties malveillantes.

Un pen test n’est pas une attaque aléatoire. Il existe des accords sur la portée, l’autorisation, l’approche, les rapports et la diligence requise. Les chercheurs utilisent des techniques que les attaquants peuvent également utiliser, mais dans le but d’améliorer la sécurité.

Dans la Méthodologie de recherche sur la sécurité de l’information avec valeur d’audit (MIAUW), nous avons discuté en détail d’une définition dirigée par M. V.A. les Pous. Cela a abouti à cette définition :

‘Une enquête de sécurité offensive menée par notre propre personnel ou par des tiers, qui implique une recherche contrôlée de vulnérabilités dans un ou plusieurs réseaux et systèmes d’information sécurisés ou dans des parties de ceux-ci, qui peuvent être utilisées pour pénétrer dans ces systèmes et/ou qui peuvent, sans intention ou de manière autonome, perturber le traitement des données de l’organisation faisant l’objet de l’enquête ou avoir d’autres conséquences néfastes.’

Lisez également Qu’est-ce que MIAUW ?.

Non, ce n’est pas nécessaire. L’objectif de MIAUW est de donner la priorité au client. Si vous payez pour un rapport, il est logique que vous ayez le contrôle sur le produit que vous achetez. C’est pourquoi MIAUW dit quelque chose à propos du fournisseur : il ne peut pas imposer de restrictions de distribution au client. Il est décrit ainsi :

Aucune restriction n’est imposée au client en matière de diffusion, de publication ou de conservation du rapport et des documents sous-jacents. Sont exclues les données financières relatives à la conduite de la recherche, telles que les taux horaires, les prix et les factures.

L’objectif principal est qu’avec un pen test, vous puissiez également démontrer que les questions importantes ont été correctement organisées. Cela est difficile si vous n’êtes pas autorisé à montrer ou à fournir les recherches à d’autres. Les informations financières sur la recherche n’ont pas besoin d’être partagées, car elles ne disent rien sur l’état de sécurité.

Le rapport contient-il trop d’informations sensibles pour les partager largement ? Le rapport d’un auditeur peut alors s’avérer utile. Cela vous permet de démontrer que l’étude a été menée et quels en ont été les principaux résultats, sans divulguer tous les détails techniques.

En bref : le client détermine quel niveau d’informations est partagé avec les partenaires, régulateurs ou autres, sans être gêné par le fournisseur.

Lisez également Qu’est-ce qu’un rapport d’audit chez MIAUW ?.

CVSS 4.0 fournit une méthode ouverte et indépendante du fournisseur pour capturer les caractéristiques techniques et la gravité d’une vulnérabilité. Le vecteur montre également quelles valeurs et hypothèses ont conduit au score. Cela rend une évaluation plus transférable et vérifiable que la simple étiquette « élevée » ou « critique ».

MIAUW utilise ce langage de mesure commun pour rendre compte de la gravité et de la justification des résultats d’une manière imitable. MIAUW ne détermine pas automatiquement si une vulnérabilité s’applique et ne prescrit pas de décision de récupération. Selon la spécification officielle de FIRST, CVSS est une contribution à l’analyse des risques, et non l’analyse complète des risques.

Non. CVSS décrit la gravité technique d’une vulnérabilité. Un risque organisationnel comprend également, par exemple, le risque d’utilisation abusive, la valeur et le fonctionnement du système, les personnes concernées, les obligations légales, les dommages possibles et les mesures de contrôle existantes.

FIRST appelle donc CVSS une entrée pour l’analyse des risques. Des facteurs tels que les dommages financiers, les dommages à la réputation, le nombre de clients concernés et les exigences légales sont couverts par expressément en dehors de CVSS. Une organisation prend en compte ces facteurs dans sa propre gestion des risques.

Oui. CVSS 4.0 inclut explicitement le contexte. Les indicateurs de menace décrivent la maturité actuelle des abus. Les mesures environnementales traitent l’environnement de déploiement concret, y compris les mesures de sécurité existantes, l’accessibilité réelle, l’importance requise de la confidentialité, de l’intégrité et de la disponibilité, les caractéristiques techniques modifiées et les conséquences possibles pour la sécurité humaine.

Les métriques supplémentaires ajoutent un contexte supplémentaire tel que la sécurité, la récupération, l’automatisation et les efforts de récupération. Ils ne modifient pas le numéro CVSS, mais selon FAQ CVSS 4.0 de FIRST ils peuvent influencer la priorité locale.

Un CVSS-B publié publiquement contient généralement uniquement les métriques de base. Cela ne revient pas à dire que CVSS n’a pas de contexte : le client complète les mesures de menace et d’environnement pour sa propre situation et reçoit ainsi un CVSS-BTE. FIRST recommande cet enrichissement pour un résultat plus significatif dans votre propre environnement.

Le score technique de base peut être le même, mais le score CVSS-BTE local ne doit pas nécessairement l’être. Un environnement de test isolé, un poste de travail interne, un service d’identité publique et un appareil critique pour la sécurité peuvent différer en termes d’accessibilité, de mesures, de protection requise et de conséquences pour d’autres systèmes ou personnes.

CVSS 4.0 peut capturer de telles différences avec les mesures de menace et d’environnement. La sécurité humaine peut également être directement prise en compte dans le score des mesures environnementales. Un contexte supplémentaire peut également influencer le classement local sans changer le nombre. Un système interne ne reçoit pas automatiquement une note inférieure : chaque ajustement doit suivre les propriétés démontrables de l’environnement réel. Voir les groupes de métriques et les règles d’évaluation de FIRST.

Oui. Un résultat du scanner ou un numéro de version correspondant ne prouve pas que le code vulnérable est présent, accessible ou exécutable. Par conséquent, vérifiez d’abord le composant et la version utilisés, la configuration, l’acheminement des appels et les éventuelles mesures. La recherche de code source, un SBOM, un VEX, une analyse de configuration et des tests dynamiques peuvent en fournir des preuves appropriées.

Si le produit ne semble pas être affecté, documentez cette non-applicabilité avec des preuves. N’attribuez pas artificiellement un faible score CVSS à une vulnérabilité qui ne s’applique pas. FIRST décrit également dans la FAQ CVSS 4.0 qu’un fournisseur doit réévaluer la note du produit en béton et peut utiliser VEX pour communiquer son applicabilité.

Une méthode uniforme donne aux fournisseurs, aux chercheurs et aux acheteurs les mêmes concepts et un vecteur lisible par machine. Cela leur permet d’échanger des évaluations, de vérifier des hypothèses et d’affiner le score pour leur propre environnement. Les recherches sur les données de vulnérabilité montrent que des évaluations de gravité incohérentes peuvent réduire considérablement la qualité d’une hiérarchisation ultérieure (Croft, Babar et Li, 2022).

Cet avantage ne signifie pas que chaque organisation doit utiliser la même séquence de récupération. L’accord significatif est le suivant : normaliser les critères, pas la décision. La menace locale, le contexte du système, la politique et l’acceptation des risques restent déterminants.

Pas dans le sens d’un modèle empirique prédisant la probabilité d’abus ou les dommages attendus. CVSS est une convention de mesure standardisée basée sur des définitions techniques et des avis d’experts. Pour la version 4.0, des millions de vecteurs possibles ont été regroupés et classés par des experts ; FIRST publie cette méthode dans le manuel d’utilisation.

Il existe des tests, mais ils sont limités. Le NIST a examiné la formule CVSS 3 contre les avis des concepteurs. Cela prend en charge le fonctionnement interne de cette formule, pas la prédiction d’incidents ou de dommages et pas automatiquement la version 4.0. La recherche révèle également des différences entre les évaluateurs humains. Le CVSS est donc utile en tant que méthode de mesure transparente et partagée, et non en tant que certitude scientifique.

Non. Un score CVSS élevé signifie que les conséquences et conditions techniques sont sévères selon le vecteur choisi. Il n’existe pas de probabilité calibrée que la vulnérabilité soit exploitée dans un certain laps de temps. La recherche montre que donner la priorité uniquement aux seuils CVSS peut ne pas être très efficace (Jacobs et coll., 2020).

CVSS 4.0 peut inclure la maturité actuelle des exploits dans les mesures des menaces. Par exemple, EPSS peut être utilisé pour une estimation de probabilité ; les attaques confirmées et les informations exclusives sur les menaces sont également pertinentes. Ces sources ne remplacent pas non plus l’évaluation des risques locaux.

Non. La politique détermine, entre autres, l’appétit pour le risque, les classes de systèmes, les délais, les exceptions, les personnes responsables et les conditions d’acceptation du risque. Le CVSS peut enregistrer de manière cohérente la gravité technique, les menaces actuelles et les facteurs environnementaux, mais ne prend pas de décision administrative.

Dans la gestion des risques, l’organisation combine ces informations avec l’applicabilité, l’impact commercial, la sécurité, la confidentialité, les obligations légales et les mesures disponibles. Elle décide alors par exemple de restaurer, limiter, éviter, transférer ou accepter avec motivation. Le score et le vecteur fournissent la preuve de cette décision ; ils ne remplacent pas la politique, la décision ou la justification exposée.

Un ordre utile est :

1. vérifier que la vulnérabilité s’applique au produit ;
2. Vérifiez le score de base CVSS et le vecteur pour ce produit ;
3. ajouter des informations actuelles sur les menaces et les facteurs environnementaux réels ;
4. inclure un contexte supplémentaire, tel que la sécurité, la récupérabilité et les obligations légales ;
5. appliquer votre propre politique en matière de priorité, de traitement et d’acceptation des risques ;
6. enregistrer la décision et les motifs.

Cela ne crée pas une liste de réparation automatique, mais une décision qui peut être suivie. FIRST recommande d’utiliser les mesures de menace et d’environnement pour obtenir un résultat plus significatif et appelle le résultat une contribution à votre propre vulnérabilité et à votre gestion des risques.

OpenKAT est l’outil ouvert d’analyse des vulnérabilités. Il s’agit d’un logiciel open source qui aide les organisations à cartographier leur paysage numérique et à rendre visibles les vulnérabilités, les erreurs de configuration et les risques.

OpenKAT est avant tout une question de perspicacité : qu’avons-nous, qu’est-ce qui est visible, qu’est-ce qui change et avec quoi devons-nous faire quelque chose ?

En savoir plus sur OuvrirKAT.

OpenKAT aide à mieux comprendre votre numérique à l’extérieur et à l’intérieur. Il collecte des informations sur les systèmes, les domaines, les logiciels et les paramètres et les convertit en informations exploitables.

En langage clair : OpenKAT permet de voir où se trouvent les portes, fenêtres et serrures numériques et lesquelles d’entre elles nécessitent une attention particulière.

En savoir plus sur OuvrirKAT.

La surface d’attaque est tout ce qu’un attaquant peut essayer d’utiliser pour accéder ou causer des dégâts.

Pensez aux sites Web, aux serveurs de messagerie, aux environnements cloud, aux API, aux VPN, aux anciens domaines, aux environnements de test oubliés et aux services mal configurés. Mieux vous connaissez cette surface, plus vous pouvez offrir une protection ciblée.

Lisez également Pourquoi une vision continue est-elle importante ?.

Les environnements numériques évoluent constamment. Des systèmes sont ajoutés, les logiciels sont mis à jour, les paramètres changent et de nouvelles vulnérabilités sont découvertes.

Une analyse ponctuelle est donc un instantané. Une vision continue permet de détecter les changements et de réagir plus rapidement lorsque quelque chose se détériore ou redevient vulnérable.

Lisez également OpenKAT peut-il afficher les changements au fil du temps ?.

Non. OpenKAT et les tests d’intrusion se complètent.

OpenKAT fournit des informations techniques continues et peut collecter de nombreux signaux. Un pen test est une enquête ciblée menée par des personnes, avec contexte, créativité et profondeur. OpenKAT peut aider à mieux cibler les tests d’intrusion et à mieux suivre les résultats.

Lisez également Qu’est-ce qu’un test d’écriture ? et OuvrirKAT.

Non. Aucun produit de sécurité ne trouve tout automatiquement.

OpenKAT permet de collecter et d’évaluer de nombreuses informations de manière structurée. Mais une bonne portée, une bonne interprétation, une bonne gestion et un bon suivi restent nécessaires. Le contexte humain reste important.

Lisez également Comment OpenKAT aide-t-il à établir des priorités ?.

Dans OpenKAT, un escroc est une petite tâche de recherche ou un scanner qui collecte des informations spécifiques. Par exemple, il peut vérifier quelque chose concernant DNS, TLS, les versions de logiciels ou d’autres propriétés techniques.

L’idée est modulaire : de nombreuses petites tâches fournissent ensemble une image plus riche de l’environnement numérique.

Lisez également Qu’est-ce que la normalisation dans OpenKAT ?.

Une constatation est un signal qui requiert de l’attention. Il peut s’agir d’une vulnérabilité, mais aussi d’un paramètre incorrect, de mesures de sécurité manquantes ou d’un écart par rapport à la politique.

Une découverte n’est pas toujours immédiatement un incident. C’est avant tout une raison pour évaluer ce que cela signifie et quel suivi est nécessaire.

Lisez également Comment OpenKAT aide-t-il à établir des priorités ?.

La sécurité fondée sur des preuves signifie que les conclusions sont basées sur des données enregistrées, et pas seulement sur des sentiments ou des hypothèses vagues.

OpenKAT aide en enregistrant les observations et en les reliant aux résultats. Il est ainsi plus facile de voir sur quoi repose une conclusion et comment la situation évolue au fil du temps.

Lisez également Pourquoi les preuves sont-elles importantes dans MIAUW ?.

La conformité consiste à démontrer que vous respectez les règles, normes ou accords. OpenKAT peut relier les observations techniques aux politiques ou aux normes.

Cela permet de mieux comprendre quelles constatations techniques sont également pertinentes sur le plan administratif ou juridique. Cela facilite les audits, les rapports et la priorisation.

Lisez également OpenKAT peut-il aider avec NIS2 ?.

Non. Les spécialistes de la sécurité ont besoin de détails techniques, mais OpenKAT est également utile aux administrateurs, aux auditeurs, aux équipes de conformité et aux directeurs.

Chaque rôle regarde différemment la même réalité : détails techniques à résoudre, aperçus à piloter et preuves à rendre compte.

En savoir plus sur OuvrirKAT.

Oui. OpenKAT est open source et peut être utilisé vous-même. Cela nécessite des connaissances techniques, une gestion et une conception minutieuse.

Certaines organisations optent donc pour l’autogestion. D’autres organisations préfèrent travailler avec un partenaire pour l’hébergement, la conception, la gestion ou le support.

Voir également Partenaires et OuvrirKAT.

OpenKAT est un outil de sécurité et doit être utilisé avec précaution. La numérisation n’est effectuée que dans un cadre convenu et avec autorisation.

Les résultats peuvent être sensibles car ils révèlent quelque chose sur les vulnérabilités et les institutions. Protégez donc bien ces informations et accordez l’accès uniquement aux personnes qui en ont besoin.

Lisez également Comment OpenKAT gère-t-il la confidentialité ?.

OpenKAT fonctionne avec des objets qui peuvent être examinés. Il peut s’agir par exemple d’un nom de domaine, d’une adresse IP, d’un site Web, d’un serveur, d’un certificat ou d’un autre composant technique.

En enregistrant ces objets séparément, OpenKAT peut établir des relations : quel site Web appartient à quel domaine, quel certificat appartient à quel service et quelle découverte appartient à quel composant.

En savoir plus sur OuvrirKAT.

Les scanners produisent souvent des résultats approximatifs. Normaliser signifie convertir cette sortie en données qu’OpenKAT peut comprendre et comparer de manière fixe.

Ceci est important car OpenKAT souhaite combiner des informations provenant de différentes sources. Ce n’est que lorsque les données sont clairement structurées que vous pouvez les relier à des objets, des résultats, des normes et des délais.

Lisez également Que signifie la sécurité fondée sur des preuves ?.

Un scanner de vulnérabilités recherche généralement des vulnérabilités techniques spécifiques. OpenKAT est plus large : il peut combiner des données provenant de plusieurs sources, établir des relations, montrer les changements au fil du temps et relier les résultats aux politiques ou aux normes.

OpenKAT peut donc utiliser des scanners, mais est lui-même avant tout une plateforme permettant de réunir observations, contexte et suivi.

En savoir plus sur OuvrirKAT.

OpenKAT est destiné à la recherche dans un cadre convenu. Ainsi, vous analysez uniquement les systèmes pour lesquels vous disposez d’une autorisation et pour lesquels il est clair ce qui peut être examiné.

Ceci est important pour des raisons juridiques, techniques et organisationnelles. La recherche sur la sécurité sans portée claire peut entraîner des risques et nuire à la confiance.

Voir également Quelle est la portée d’une enquête MIAUW ?.

Oui. Une idée importante derrière OpenKAT est que vous ne voulez pas seulement un instantané, vous voulez également voir comment la situation évolue.

Cela aide à répondre à des questions telles que : un problème a-t-il été résolu, est-il réapparu, quelque chose de nouveau est-il apparu et la situation sécuritaire s’améliore-t-elle ou se détériore-t-elle ?

Lisez également Pourquoi une vision continue est-elle importante ?.

Toutes les découvertes n’ont pas la même urgence. Un problème technique sur un système de test sans importance est souvent moins grave que le même problème sur un système public contenant des données sensibles.

OpenKAT aide en reliant les signaux techniques au contexte, aux politiques et aux normes. Cela permet à une organisation de mieux déterminer ce qui doit être abordé en premier.

Lisez également Comment OpenKAT contribue-t-il à la conformité ?.

OpenKAT peut contribuer à l’aspect pratique d’une résilience numérique démontrable : obtenir un aperçu des systèmes, des vulnérabilités, des erreurs de configuration et des changements au fil du temps.

NIS2 ne concerne pas seulement la technologie, mais aussi la gouvernance, les risques et la démontrabilité. OpenKAT peut fournir un support technique pour cela, mais ne remplace pas un programme NIS2 complet.

Lisez également Comment OpenKAT contribue-t-il à la conformité ?.

OpenKAT examine principalement les données techniques, mais les résultats peuvent être sensibles. Un rapport de vulnérabilité ou d’erreur de configuration peut être utilisé à mauvais escient s’il se retrouve au mauvais endroit.

C’est pourquoi il est important de limiter l’accès, de bien protéger les résultats et de scanner uniquement dans un périmètre clair.

Lisez également les politique de confidentialité de ce site Web et L’utilisation d’OpenKAT est-elle sûre ?.

Les résultats d’analyse individuels sont souvent difficiles à interpréter. Les relations indiquent clairement comment les composants sont liés : quel domaine appartient à quel site Web, quel service s’exécute sur quel système et quelle découverte appartient à quel objet.

Ces relations font d’OpenKAT plus qu’une liste de notifications. Il devient un modèle de l’environnement numérique qui permet de mieux comprendre les causes, l’impact et le suivi.

En savoir plus sur OuvrirKAT.

Oui. OpenKAT est intéressant car il peut combiner des informations provenant de différentes sources. Tenez compte des scanners, des sources de données externes, des contrôles de configuration et de vos propres tâches de recherche.

L’objectif n’est pas de remplacer tous les outils, mais de mieux rassembler les résultats et de les rendre utiles à l’analyse, au suivi et à la responsabilisation.

En savoir plus sur OuvrirKAT.

OciDeck est un programme de présentation axé sur le contenu. Vous créez des diapositives à partir de formes de diapositives, de données et de texte clairs, au lieu de faire glisser manuellement des objets sur un canevas.

En savoir plus sur OciDeck.

OciDeck est destiné aux personnes qui considèrent les présentations comme des supports de connaissances. Pensez aux formateurs, chercheurs, professionnels de la sécurité, développeurs, auditeurs, décideurs politiques et organisations qui souhaitent garder le contrôle de leurs informations.

C’est particulièrement intéressant lorsque le contenu, la réutilisation, la vérifiabilité et le partage sécurisé sont importants.

Pour en savoir plus, consultez OciDeck et Caractéristiques d’OciDeck.

De nombreux logiciels de présentation démarrent avec une toile vierge. Vous faites glisser les zones de texte, les images et les formes en place.

OciDeck commence par le contenu. Vous choisissez le type de slide, remplissez le contenu et laissez la présentation en découler. Cela facilite la vérification, la réutilisation et l’exportation des diapositives.

Lisez également Pourquoi Marp est important pour OciDeck.

Marp est un moyen de créer des présentations avec Markdown. Markdown est une simple notation de texte.

Marp est important pour OciDeck car il signifie que la présentation reste du texte brut. Cela rend les modifications contrôlables et garantit que le contenu n’est pas verrouillé dans un format de fichier fermé.

En savoir plus sur Pourquoi Marp est important pour OciDeck.

Pas nécessairement. OciDeck propose des éditeurs structurés par type de diapositive. Vous pouvez donc travailler sans écrire Markdown à tout moment.

Markdown est avant tout la base ouverte de la présentation. Quiconque connaît Markdown peut en bénéficier, mais ce n’est pas une exigence stricte pour chaque utilisation.

Lisez également Qu’est-ce que Marp ?.

Les présentations contiennent souvent des informations plus sensibles qu’on ne le pense : noms, adresses e-mail, détails des clients, jetons, captures d’écran, notes du conférencier ou détails techniques.

OciDeck permet de rendre ces informations visibles plus tôt, avant qu’une présentation ne soit partagée ou exportée.

En savoir plus sur Fonctionnalités de confidentialité dans OciDeck.

OciWacht recherche localement des données potentiellement sensibles dans une présentation. Pensez aux numéros d’identification, aux adresses e-mail, aux numéros de téléphone, aux jetons, aux clés ou à d’autres modèles sensibles.

Pour chaque résultat, le créateur peut choisir quoi en faire : accepter, marquer ou omettre de la présentation et de l’exportation.

En savoir plus sur Fonctionnalités de confidentialité dans OciDeck.

Non, pas pour le traitement normal de votre présentation. OciDeck web fonctionne dans votre navigateur : l’application Flutter web est chargée depuis le serveur, puis l’édition, l’aperçu en direct, OciWacht, l’export vers PDF/PPTX/HTML et le générateur CVSS se font côté client. Le contenu de la présentation n’est pas envoyé à un backend pour être traité.

Il n’y a pas non plus de télémétrie ni d’analytics intégrés. Le serveur d’hébergement d’OciDeck n’a donc pas de visibilité applicative sur votre présentation, vos modifications, les résultats de confidentialité ou les exports.

Il y a toutefois des nuances. Comme tout webhost, le serveur peut avoir des journaux d’accès ordinaires, par exemple l’adresse IP, l’heure, les fichiers demandés et le user-agent. Cela montre que quelqu’un a chargé l’application, mais pas ce que cette personne fait dans OciDeck.

Il existe aussi un fetch proxy optionnel pour l’import d’URL lorsqu’une source n’autorise pas l’accès CORS. Ce n’est que lorsque vous ouvrez une telle URL non-CORS via ce proxy que le serveur voit l’URL saisie et relaie les octets.

Les autres connexions sortantes sont initiées par l’utilisateur et vont vers des destinations que vous choisissez ou configurez vous-même, comme l’assistance IA optionnelle, WebDAV/Nextcloud, une base CVE, le provisioning de secmodule ou une URL que vous importez vous-même.

Pour utiliser OciDeck dans le navigateur, rendez-vous sur ocideck.nl.

En savoir plus sur Fonctionnalités de confidentialité dans OciDeck.

Non, aucune analyse ne trouve tout.

OciWacht est un outil permettant d’identifier les risques plus tôt et de les partager de manière plus consciente. Le créateur reste responsable du contenu et doit toujours penser par lui-même dans les présentations sensibles.

Lisez également Pourquoi les fonctionnalités de confidentialité d’OciDeck sont-elles importantes ?.

Toutes les diapositives ne sont pas destinées à tous les publics. OciDeck peut aider à déterminer par présentation et par diapositive dans quelle mesure les informations peuvent être partagées.

OciDeck peut ainsi éviter qu’une diapositive interne ne se retrouve accidentellement dans une présentation ou une exportation plus large.

En savoir plus sur Partagez au bon niveau.

TLP signifie Protocole de feux de circulation. Il s’agit d’un système de couleurs permettant d’indiquer le degré de confidentialité des informations et avec qui ces informations peuvent être partagées.

Vous n’avez pas besoin de connaître l’abréviation pour comprendre le principe. La question pratique est la suivante : qui est autorisé à voir ces informations ?

En savoir plus sur Partagez au bon niveau.

Oui. Les graphiques dans OciDeck restent connectés aux données. Cela les rend plus contrôlables et moins dépendants des captures d’écran ou des images créées manuellement.

Ceci est utile pour les recherches, les rapports, les tableaux de bord et les présentations où les chiffres doivent rester corrects.

En savoir plus sur Caractéristiques d’OciDeck.

Oui. Les listes de contrôle peuvent être cochées lors de la présentation.

Ceci est utile pour les formations, les ateliers, les démonstrations, les examens de sécurité et les rapports dans lesquels les progrès doivent être visibles. La liste de contrôle devient alors une partie de l’histoire et non un ajout à la présentation.

En savoir plus sur Caractéristiques d’OciDeck.

Oui. OciDeck se concentre sur le travail à partir d’une source unique et l’exportation vers des formats utilisables tels que PDF, PPTX et HTML hors ligne autonome.

L’avantage est que le même contenu peut être utilisé à des fins différentes, sans avoir à créer manuellement de nouvelles copies à chaque fois.

En savoir plus sur Caractéristiques d’OciDeck.

Oui. OciDeck est open source. Le code source est dans Forgejo :

https://pawprint.vigilis.online/LibreKAT/OciDeck

Lisez également OciDeck.

Les formes de diapositive sont des types fixes de diapositives, tels qu’un titre, une liste, un tableau, un graphique, un exemple de code, une question, une chronologie ou un tableau de bord.

En travaillant avec des formes de diapositives, le créateur doit moins faire défiler manuellement. Le contenu est central et OciDeck peut afficher, contrôler et exporter ce contenu de manière plus cohérente.

En savoir plus sur Caractéristiques d’OciDeck.

Oui. OciDeck prend en charge les diapositives avec code source et coloration syntaxique. Le code reste du vrai texte au lieu d’une capture d’écran.

Ceci est utile pour les présentations techniques, les formations et les rapports de sécurité dans lesquels le code doit rester lisible et auditable.

En savoir plus sur Caractéristiques d’OciDeck.

Oui. OciDeck peut utiliser des diapositives Markdown gratuites, notamment des diagrammes Mermaid et des mathématiques LaTeX.

Cela signifie que les graphiques et les formules peuvent être enregistrés en tant que contenu source, plutôt que sous forme d’image distincte difficile à modifier ultérieurement.

En savoir plus sur ce qui rend Marp Markdown possible.

Le mode Markdown est destiné aux utilisateurs qui souhaitent travailler directement dans la source texte d’un deck. Cela peut être utile pour la recherche et le remplacement, les modifications rapides de texte ou la vérification technique.

Vous n’êtes pas toujours obligé d’utiliser le mode Markdown. Les éditeurs structurés restent là pour ceux qui préfèrent travailler par slide.

Lisez également Qu’est-ce que Marp ?.

OciDeck comprend un module de test de stylet MIAUW en option. Ce module est destiné aux rapports selon la méthodologie de recherche sur la sécurité de l’information avec valeur d’audit.

Pensez à rechercher des diapositives, des résumés, des listes de contrôle, des aperçus de la portée et une aide à la création de rapports. Le module est désactivé par défaut et est destiné aux situations où MIAUW est vraiment pertinent.

Pour en savoir plus, consultez Caractéristiques d’OciDeck et Qu’est-ce que MIAUW ?.

L’exportation HTML hors ligne signifie qu’une présentation peut être transportée ou partagée en tant que version HTML autonome, sans avoir besoin d’un accès réseau pendant l’affichage.

Ceci est utile pour les formations, les démonstrations et les environnements dans lesquels vous ne souhaitez pas dépendre de présentations cloud ou de services externes.

En savoir plus sur Caractéristiques d’OciDeck.

Oui. OciDeck prend en charge les présentations avec, entre autres, l’affichage plein écran, la navigation au clavier, la minuterie, les notes, le mode répétition et le présentateur double écran.

Cela fait d’OciDeck non seulement un éditeur, mais également un outil permettant de faire des présentations.

En savoir plus sur Caractéristiques d’OciDeck.

Oui. OciDeck peut fonctionner avec les notes du présentateur et les notes séparées pour les participants.

Ceci est utile car toutes les informations ne doivent pas nécessairement figurer sur la diapositive elle-même. Un orateur peut avoir besoin d’un contexte supplémentaire, tandis que les participants ont besoin d’un résumé ou d’une référence soignée.

En savoir plus sur Caractéristiques d’OciDeck.

Oui. OciDeck peut utiliser Nextcloud/WebDAV comme source pour les packages OciDeck et les decks Marp Markdown.

Cela convient aux organisations qui préfèrent conserver leurs documents sous leur propre gestion ou dans leur propre environnement collaboratif.

En savoir plus sur Caractéristiques d’OciDeck.

OciDeck se concentre sur une interface accessible, comprenant les commandes du clavier, les étiquettes du lecteur d’écran, l’échelle du texte et les annonces de changement de diapositive.

L’accessibilité est aussi une question de structure. Étant donné que les diapositives contiennent du contenu réel, il est plus facile de garder ce contenu compréhensible et vérifiable.

En savoir plus sur Caractéristiques d’OciDeck.

Utilisez-vous Homebrew ? Exécutez ensuite ces deux commandes. Le premier pointe Homebrew vers notre propre forge, le second installe OciDeck :

brew tap librekat/ocideck https://pawprint.vigilis.online/LibreKAT/homebrew-ocideck.git
brew install --cask librekat/ocideck/ocideck

La ligne d’adresse en fait vraiment partie. Si vous omettez cela, Homebrew recherchera GitHub et ne trouvera rien.

C’est la voie canonique : la recette et l’application proviennent de notre propre forge. Si la forge est temporairement indisponible, le miroir GitHub constitue la copie de sauvegarde. Cela se fait en une seule commande, car la forme courte de Homebrew pointe par définition vers GitHub :

brew install --cask brennodewinter/ocideck/ocideck

Quelle que soit la manière dont vous installez, Homebrew extrait la version directement de notre propre forge et vérifie automatiquement la somme de contrôle. L’application est signée avec un identifiant de développeur Apple et notariée par Apple, elle s’ouvre donc d’un simple double-clic.

Pour passer à une version ultérieure, exécutez :

brew upgrade --cask ocideck

La cask n’est qu’un renvoi vers cette même version signée et notariée ; Homebrew n’héberge pas l’application lui-même et aucun intermédiaire supplémentaire n’intervient. Homebrew Cask n’existe que pour macOS — sous Windows et Linux, vous téléchargez OciDeck directement.

Vous préférez sans Homebrew ? Téléchargez alors OciDeck directement depuis la page OciDeck. Vous y trouverez aussi, par plateforme, comment ouvrir et vérifier le téléchargement.