ENParlons de votre projet
Menu

Adrien Murillo

Apprendre en prenant des décisions.

Trois scénarios interactifs, des corrections expliquées et des ressources open source pour poursuivre en atelier.

LAB / 3 scénarios · 3 décisions chacun

À vous de décider.

Organiser un atelier ↗

Lisez la situation, choisissez une action, puis confrontez votre raisonnement au débrief. Scénarios fictifs à visée pédagogique, sans diagnostic ni classement de compétences.

Lire tous les scénarios et leurs corrections

Incident & gouvernance

Une plateforme interne devient indisponible. Un compte administrateur présente une connexion inhabituelle. Vous participez à la cellule de décision.

Les premières minutes

Vous ne savez pas encore si la panne et la connexion sont liées. Quelle première décision proposez-vous ?

Mobiliser les responsables, contenir le compte suspect et préserver les traces utiles.

La coordination permet de décider du périmètre de confinement avec l’exploitation. Préserver les traces aide à vérifier les hypothèses. Une reconstruction générale trop tôt peut effacer des éléments utiles.

Preuve utile : Horodatage, compte concerné, systèmes touchés et décision de confinement.

La pression pour redémarrer

Une sauvegarde est disponible. Le métier demande une reprise immédiate. Que faut-il établir ?

Que la sauvegarde est exploitable et que la restauration peut être vérifiée dans un environnement maîtrisé.

L’existence d’une sauvegarde ne prouve ni son intégrité ni la capacité de reprise. Il faut définir les contrôles techniques et métiers, puis valider le résultat de la restauration.

Preuve utile : Rapport de restauration, contrôles d’intégrité et validation métier.

Accepter le risque restant

Le service peut reprendre avec une mesure temporaire. Une faiblesse reste ouverte. Comment organiser la décision ?

Faire valider le risque par le responsable habilité, avec une action, un propriétaire et une date de réexamen.

L’arbitrage doit appartenir au responsable du risque. La mesure temporaire devient suivable si sa portée, son propriétaire et sa date de réexamen sont explicites.

Preuve utile : Décision datée, risque résiduel, responsable et échéance.

Assistant IA & permissions

Une équipe prépare un assistant qui consulte des documents internes et peut créer des tickets. Vous relisez son architecture avant le pilote.

Une consigne dans un document

Un document récupéré demande à l’assistant d’envoyer son contexte à une adresse externe. Quel contrôle est prioritaire ?

Traiter le document comme une donnée non fiable et interdire les sorties et outils non autorisés.

Le contenu récupéré ne doit pas devenir une instruction de confiance. Les contrôles d’accès et de sortie doivent être appliqués par le système qui exécute les actions, avec des tests sur les scénarios d’injection.

Preuve utile : Test d’injection avec vérification des appels d’outils et des sorties réseau.

Le bon document, la mauvaise personne

L’assistant cite un document que l’utilisateur n’a pas le droit de lire. Où placer le contrôle ?

Dans la recherche et l’accès aux documents, avec l’identité et les droits de l’utilisateur.

Une réponse filtrée trop tard peut déjà exposer des données. La recherche doit appliquer les autorisations avant de transmettre les documents au modèle, puis vérifier les sorties selon le contexte.

Preuve utile : Tests croisés avec deux identités et des documents de droits différents.

Passer de la suggestion à l’action

Le pilote peut maintenant modifier des tickets existants. Quelle condition ajoutez-vous ?

Une autorisation précise par action, une validation humaine pour les effets sensibles et un journal des changements.

L’autonomie doit rester proportionnée aux effets. Une permission précise et une validation des actions sensibles réduisent la portée d’une erreur. Le journal permet de retrouver ce qui a été modifié.

Preuve utile : Matrice des actions autorisées et test d’une modification refusée.

Rust & robustesse

Vous concevez un petit outil Rust qui importe une configuration et appelle une API. Le compilateur est satisfait. Vous préparez la livraison.

Une entrée inattendue

Une valeur obligatoire manque dans le fichier. Quel comportement préparez-vous ?

Une erreur explicite et testée, sans effet partiel non documenté.

Le compilateur ne définit pas le comportement métier d’une entrée invalide. Une erreur explicite rend le diagnostic possible. Tester ce chemin évite qu’un échec banal devienne une interruption incompréhensible.

Preuve utile : Test d’import invalide, message d’erreur utile et code de sortie non nul.

Une API qui ne répond plus

L’outil attend une réponse externe. Que devez-vous préciser ?

Une limite de temps, une stratégie de reprise et les opérations qui peuvent être rejouées.

Le langage ne fixe pas la politique réseau. Une reprise peut dupliquer une action si elle n’est pas idempotente. Délai, nombre de tentatives et comportement en échec doivent être décidés et testés.

Preuve utile : Test de timeout et vérification qu’une reprise ne duplique pas une action.

Le passage à une autre équipe

Le binaire fonctionne sur votre poste. Que livrez-vous en complément ?

Le code, les versions de dépendances, les instructions et les tests qui décrivent le contrat de l’outil.

La reprise exige de pouvoir reconstruire et vérifier le composant. Les limites et le contrat d’erreur comptent autant que le scénario nominal.

Preuve utile : Construction dans un environnement propre et exécution documentée des tests.

Prolonger la pratique

Trois ressources open source.

Des supports repérés sur GitHub pour aller plus loin en atelier. Ils sont proposés par leurs auteurs respectifs et ne sont pas intégrés au site.

MIT

Rustlings

Des exercices de Rust à résoudre avec le compilateur. Pour pratiquer progressivement les types, les erreurs et les tests.

En local · Rust et Cargo nécessaires

Voir le dépôt GitHub ↗
GPL-3.0

Backdoors & Breaches

Un support pour animer une simulation de réponse à incident. Utile pour faire discuter les rôles et l’ordre des actions.

Atelier animé · préparer le scénario et les règles

Voir le dépôt GitHub ↗
MIT

OWASP Juice Shop

Une application volontairement vulnérable pour apprendre la sécurité web par défis. À utiliser dans un laboratoire isolé.

Laboratoire séparé · installation requise

Voir le dépôt GitHub ↗

Le jeu de décisions ci-dessus est un exercice original du site. Les dépôts cités servent de ressources complémentaires. Leur code n’a pas été copié.

Explorer avec des limites claires

Ce qui se vérifie en public.

Tous les projets ↗

La sécurité IA est ici un champ d’exploration technique documentée, sans revendication de missions professionnelles IA.

LAB / SIGNAL

Capter le signal.

Une courte pause dans le Lab. Attrapez les cercles, évitez les croix. Trois vies, 40 secondes. Aucune donnée ne quitte cette page.

Signaux 00Vies 3Secondes 40

Flèches du clavier, A / D ou boutons pour se déplacer. P pour la pause. Échap pour arrêter.

À vous de jouer.

L’assistant du site

Parlons de votre besoin.

Je vous aide à explorer les missions, le parcours d’Adrien et les ressources du site.

Confidentialité de la discussion