ENSe connecter

Votre première expérience professionnelle, avant votre premier emploi.

Chaque lab vous plonge dans un vrai cas d'entreprise. Vous le résolvez vous-même, et vous gagnez ce que la théorie ne donne pas : la confiance.

Créer un compte

Votre premier atelier est offert.

Labs (52)

Choisissez votre prochain défi. Chaque lab est conçu par des experts, à partir de missions qu'ils mènent en entreprise.

37–48 sur 52 labs

  • GénéralParcours : SQL et PostgreSQL : de la première requête à l'optimisation

    PostgreSQL : contraintes, types et droits d'accès

    Mama Ngo est rentrée du village. Pendant son absence, sa nièce Nadia a tenu la caisse une semaine entière. « Il y a des ventes à zéro, un moyen de paiement que personne ne connaît, et le riz en double. La machine ne pouvait pas refuser toute seule ? » À l'atelier précédent, vous avez appris à écrire prudemment. Mais la prudence ne protège que ce que vous tapez vous-même. La seule protection qui vaut pour tout le monde, c'est la base qui refuse. Vous commencez par retrouver les dégâts avec les requêtes que vous connaissez, puis vous tentez de poser la règle qui les aurait empêchés, et la base refuse de la créer : des lignes existantes la violent déjà. Ce refus devient votre plan de nettoyage. Vous nettoyez sans rien perdre, après avoir demandé à Nadia ce qui s'est vraiment passé, car une donnée étrange n'est pas forcément fausse. Puis vous posez les règles que la base fera respecter à tout le monde : CHECK, UNIQUE, DEFAULT. Vous fusionnez le riz en double malgré la clé étrangère qui s'y oppose, vous choisissez le type de chaque information d'un bon de livraison, et vous créez la table des livraisons, avec sa numérotation automatique et son lien vers les produits. Enfin, vous découvrez qu'une table neuve est fermée à tous, et vous donnez le droit de la lire, et seulement de la lire. Tout se passe dans le terminal, avec le compte du propriétaire de la base. À la fin, les règles posées et la table créée sont vérifiées dans la base, et le résultat compte pour votre classement.

    • Aucun avis
    • Intermédiaire
    • 2 h
    • 750 crédits
    • 1er atelier offert
  • GénéralParcours : SQL et PostgreSQL : de la première requête à l'optimisation

    SQL avancé : sous-requêtes, WITH (CTE) et fonctions de fenêtrage

    La boutique connaît enfin ce qu'elle paie au grossiste. Mama Ngo a deux questions : « Est-ce que septembre a été meilleur qu'août ? Et sur quoi je gagne vraiment, une fois payé le grossiste ? » Aucune des deux ne tient dans une requête simple. La première compare un mois au précédent, la seconde croise des tables regroupées différemment. C'est le nouveau mur du SQL : la question qui demande plusieurs étapes. Vous apprenez à l'écrire comme on la pense, une étape nommée après l'autre, chacune vérifiable seule. En chemin, trois pièges qui ne lèvent aucun message. Une division entre entiers qui affiche 0 % au lieu de 58 %. Un NOT IN qui rend zéro ligne parce qu'un seul vide traîne dans la liste. Et une jointure directe entre deux tables qui multiplie les montants sans prévenir. Chacun est provoqué sur des chiffres que vous connaissez, pour que vous voyiez qu'ils sont faux au lieu de les croire. Vous regroupez par mois et par jour de la semaine, vous calculez la marge de chaque produit avec WITH, vous classez avec CASE, et vous découvrez les fonctions de fenêtre : lag pour comparer chaque mois au précédent, rank pour classer sans regrouper. Le challenge : le produit le plus rentable de chaque rayon. Et une surprise dans les chiffres : ce qui remplit la caisse n'est pas ce qui fait vivre la boutique.

    • Aucun avis
    • Intermédiaire
    • 2 h
    • 750 crédits
    • 1er atelier offert
  • GénéralParcours : SQL et PostgreSQL : de la première requête à l'optimisation

    PostgreSQL : accélérer une requête avec EXPLAIN et les index

    La boutique a rejoint la coopérative des commerçants de Nkoldongo : quarante boutiques, une seule base, un million de ventes. Le président appelle Mama Ngo : « Quand un client fidèle passe, l'écran met un temps fou à sortir son historique. Et le samedi, c'est pire. » Aucune requête n'est fausse : elles sont lentes. Et devant une requête lente, la tentation est d'essayer des choses au hasard. Cet atelier fait l'inverse : avant d'accélérer une requête, on lit comment PostgreSQL l'exécute. Vous mesurez, puis vous lisez le plan avec EXPLAIN et EXPLAIN ANALYZE : un million de lignes lues pour en rendre quatorze, par trois processus en parallèle. Vous créez l'index qui change le plan, et vous le prouvez par le plan lui-même, en apprenant à y chercher un seul mot. Puis les trois cas où un index existe et ne sert à rien : une fonction sur la colonne, une condition trop peu sélective, une recherche au milieu d'un texte. Vous mesurez aussi ce qu'un index coûte à chaque écriture, et vous supprimez celui qui ne sert pas. Enfin, la recherche plein texte : chercher des mots plutôt que des lettres, au pluriel comme au singulier, en majuscules ou non, avec l'index qui la fait passer de plus d'une seconde à quelques dizaines de millisecondes. Le challenge : le tableau de bord du samedi, et l'index sur deux colonnes qui le rend instantané.

    • Aucun avis
    • Intermédiaire
    • 2 h 15 min
    • 1 000 crédits
    • 1er atelier offert
  • GénéralParcours : SQL et PostgreSQL : de la première requête à l'optimisation

    PostgreSQL : transactions, verrous et interblocages

    Mama Ngo a acheté une seconde caisse. Samedi dernier, il ne restait qu'une bouteille d'huile végétale : « Une dame l'a payée chez Nadia pendant qu'un monsieur la payait chez moi. Deux tickets, une seule bouteille. La machine n'a pas vu qu'on vendait la même chose en même temps ? » Tant qu'il n'y avait qu'une caisse, les ventes passaient l'une après l'autre. Avec deux, elles se croisent. Cet atelier ouvre deux terminaux, un par caisse, et rejoue le samedi dans l'ordre exact où les deux caisses agissent. Vous voyez d'abord ce qu'une session voit du travail d'une autre, avant et après COMMIT, puis vous reproduisez la vente fantôme : aucune erreur, deux ventes validées, une bouteille. Vous rencontrez votre premier verrou, un terminal qui ne rend pas la main parce que l'autre caisse tient la ligne. Puis vous écrivez la vente qui ne peut pas survendre, en laissant la base compter, et vous voyez PostgreSQL relire la ligne après l'attente. Vous réservez une ligne avant de décider avec SELECT FOR UPDATE, vous travaillez dans un cliché figé en REPEATABLE READ jusqu'à l'erreur de sérialisation, et vous provoquez un interblocage que la base dénoue en sacrifiant l'une des deux caisses. Et une dernière scène : la transaction oubliée qui fige tout le monde. La retrouver et la couper, c'est le métier d'administrateur, et c'est le défi qui clôt le parcours.

    • Aucun avis
    • Intermédiaire
    • 2 h 15 min
    • 1 000 crédits
    • 1er atelier offert
  • GénéralParcours : SQL et PostgreSQL : de la première requête à l'optimisation

    Défi PostgreSQL : débloquer une session qui fige la caisse

    Samedi, 10 h. La boutique est pleine, et la caisse de Nadia tourne dans le vide. Elle ne plante pas, elle n'affiche rien : elle attend. Ludovic ne répond pas au téléphone. Mama Ngo attend avec une cliente, un paquet de sardines à la main. Ce défi n'a pas de guide pas à pas. Il a une mission, des règles, et la documentation officielle de PostgreSQL. Vous êtes pour la première fois de l'autre côté du serveur : superutilisateur, avec la vue sur toutes les sessions ouvertes, ce que chacune fait, et ce que chacune attend. À vous de remonter de la caisse bloquée jusqu'à la session qui la bloque, de comprendre ce qu'elle tient et depuis quand, puis de la couper, elle seule, sans redémarrer le serveur ni arrêter la caisse. Il faudra aussi que cela ne se reproduise pas : régler le serveur pour qu'une transaction oubliée ne puisse plus bloquer la boutique plus de trente secondes, et laisser un mot à Ludovic pour qu'il comprenne ce qui s'est passé. C'est exactement le travail d'un administrateur de bases de données : observer, comprendre, intervenir sans interrompre le service, et s'appuyer sur la documentation. La suite naturelle de ce parcours.

    • Aucun avis
    • Intermédiaire
    • 1 h 30 min
    • 1 000 crédits
    • 1er atelier offert
  • DébutantParcours : Linux : administration système, préparation au LFCS

    Linux : inventorier un serveur (services, ports, journaux)

    Le prestataire qui gérait le serveur ERP est parti il y a trois semaines, sans rien transmettre. Personne ne sait ce qui tourne dessus, ni ce qui redémarrerait tout seul après une coupure de courant. La direction ne vous demande pas de réparer : elle veut un inventaire écrit, pour que le prochain incident ne se règle pas à l'aveugle. Vous partez d'un shell et de rien d'autre. C'est la situation par laquelle presque tout administrateur système commence, et celle qu'aucun cours ne prépare. Le guide ne vous donne pas les réponses : il vous donne les questions et les outils, et vous cherchez sur la machine avant d'ouvrir la solution. Vous apprendrez à lire l'arborescence pour séparer ce qu'un paquet a installé de ce qu'un humain a posé à la main, à demander à systemd à qui appartient un processus, et à mettre un nom sur chaque port en écoute. En chemin, vous tomberez sur ce que tout serveur hérité cache : des données métier qu'aucune sauvegarde standard ne prendrait, un programme que personne ne surveille, et un script qui marche à la main mais échouerait en service. Vous ne corrigez rien, vous documentez. Votre inventaire est relu sur la machine à la fin du lab, et il compte pour votre classement. Un vrai serveur, avec ses services en production et ses journaux. Le terminal s'ouvre dans votre navigateur : ni clé SSH, ni installation.

    • Aucun avis
    • Débutant
    • 1 h 45 min
    • 500 crédits
    • 1er atelier offert
  • DébutantParcours : Linux : administration système, préparation au LFCS

    Linux : utilisateurs, groupes et permissions

    Deux exploitants et une comptable arrivent lundi. Aujourd'hui tout le monde se connecte avec le même compte admin, dont le mot de passe est noté sur un post-it. Le commissaire aux comptes a posé trois conditions pour valider l'exercice : des comptes nominatifs, un accès aux pièces comptables limité aux personnes concernées, et la traçabilité des actions d'administration. Vous avez le week-end. La gestion des droits est ce qu'on confie le plus tôt à un administrateur débutant, et ce qui se fait le plus souvent de travers : un chmod 777 qui règle le problème du jour et ouvre celui de l'année. Vous commencerez par l'audit, et il réserve une surprise : un ancien salarié a gardé les pleins pouvoirs. Puis vous traduirez le besoin métier en groupes, vous construirez un partage où chaque nouveau fichier reste modifiable par toute l'équipe (groupe, setgid, umask), et vous accorderez par sudo une commande précise au lieu du pouvoir root. Le serveur est en service, et l'ordre des gestes compte autant que les gestes : construire, prouver sous l'identité de chaque arrivant, et seulement ensuite fermer les anciens accès. Le guide vous fait prédire le résultat avant chaque commande, parce que c'est l'écart entre ce que vous attendiez et ce que vous voyez qui fait comprendre les permissions Unix. À la fin, l'état de la machine est vérifié et compte pour votre classement. Sandbox prête, terminal dans le navigateur, aucune clé à gérer.

    • Aucun avis
    • Débutant
    • 2 h 30 min
    • 750 crédits
    • 1er atelier offert
  • GénéralParcours : Linux : administration système, préparation au LFCS

    Linux : corriger une faille avec apt et dnf (Debian, RHEL)

    Une faille critique vient d'être publiée sur GnuTLS, la bibliothèque de chiffrement présente sur tout votre parc, et elle doit être corrigée sous 24 heures. Sauf que l'éditeur de l'ERP vous a écrit ce matin : son connecteur n'est certifié qu'avec la version de curl actuellement installée. Toute montée de version de curl arrête la facturation. Il faut donc corriger la faille sans laisser curl bouger, sur les deux moitiés du parc, et pouvoir le justifier devant l'auditeur. Un parc homogène n'existe que dans les formations. Ici vous travaillez les deux familles en parallèle, un serveur de la famille RHEL et un conteneur Debian 12 resté à sa version de 2023, et vous apprenez à traduire chaque opération de l'une vers l'autre : dpkg et rpm pour savoir, apt et dnf pour changer. Premier piège, celui qui fait échouer la plupart des débutants : le paquet ne porte ni le nom de la commande, ni le même nom d'une distribution à l'autre. Vous regarderez ce qu'une mise à jour emporterait avant de la lancer, vous corrigerez le strict nécessaire et vous le prouverez par la version installée, pas par l'absence d'erreur. Puis vous gèlerez curl des deux côtés, vous essaierez de forcer le verrou, et vous documenterez la dette que ce gel crée, avec sa date de levée. C'est ce dernier point qu'on vous reprochera s'il manque. À la fin, la machine et votre fiche sont vérifiées, et le résultat compte pour votre classement. Terminal dans le navigateur, aucune installation.

    • Aucun avis
    • Intermédiaire
    • 2 h 50 min
    • 1 000 crédits
    • 1er atelier offert
  • GénéralParcours : Linux : administration système, préparation au LFCS

    Linux : disque plein et extension d'un volume LVM

    3 h 12 du matin. L'astreinte sonne : plus aucune facture ne part, le volume /srv/factures est à 100 %. Il faut rétablir le service cette nuit, sans redémarrer le serveur, sans rendre /etc/fstab invalide, et sans supprimer quoi que ce soit qui ait une valeur comptable. Au matin, la direction posera une seule question : pourquoi personne n'a été prévenu avant la panne ? « Disque plein » recouvre trois pannes différentes, et elles ne se soignent pas pareil. Le guide vous fait diagnostiquer avant de toucher : vous prédisez ce que df et du vont répondre, et leur désaccord vous mène à un fichier supprimé la veille mais toujours tenu ouvert par un service, qui occupe encore des centaines de mégaoctets. Vous rendez cet espace sans effacer un seul fichier, puis vous étendez le volume logique et son système de fichiers à chaud, sans démonter et sans interrompre la facturation. Le lab va ensuite là où s'arrêtent les tutoriels. Décider si le swap est un remède ou un symptôme en lisant l'usage réel de la mémoire, plutôt que d'obéir à une règle toute faite. Puis poser ce qui manquait vraiment : une mesure du remplissage, planifiée par un timer systemd, et une alarme CloudWatch avec un seuil qui laisse le temps d'agir en journée. À la fin, l'état de la machine et l'alarme sont vérifiés, et le résultat compte pour votre classement. Un serveur réel, en conditions d'incident.

    • Aucun avis
    • Intermédiaire
    • 3 h 15 min
    • 1 500 crédits
  • GénéralParcours : Linux : administration système, préparation au LFCS

    Réseau Linux : routage et pare-feu nftables

    L'entreprise a changé d'opérateur Internet il y a deux jours. Depuis, les clients n'arrivent plus à suivre leurs conteneurs en ligne, alors qu'au bureau le portail s'affiche parfaitement. L'opérateur a répondu à votre ticket en une heure : le problème ne se situe pas chez lui. La direction vous donne la matinée pour rendre le portail aux clients, et pour répondre par écrit à une seule question : qui avait raison ? Vous commencez par délimiter la panne au lieu de chercher au hasard : le même test depuis le bureau et depuis Internet écarte la moitié des suspects. Puis une capture de paquets tranche le débat avec l'opérateur, preuve à l'appui. Vous descendez ensuite couche par couche : l'adresse, la route, les voisins, et une passerelle qui n'existe plus depuis le changement de box. Vous apprenez à reconnaître, à la seule forme de l'erreur, un service qui n'écoute pas d'un pare-feu qui filtre, et vous prenez le pare-feu sur le fait dans le journal du noyau. Le lab va là où s'arrêtent les tutoriels. Comprendre pourquoi une règle fausse depuis le premier jour a fonctionné pendant des années. Ouvrir exactement un port dans nftables, sans ouvrir l'administration à Internet ni fermer le bureau. Puis rendre chaque correction durable, et le prouver sans redémarrer, avant de rédiger le rapport d'incident que liront la direction et l'opérateur. Le bureau, la box de l'opérateur et un client sur Internet sont simulés sur la machine : vous pouvez casser la route et le pare-feu sans perdre votre terminal. À la fin, l'état du serveur et votre rapport sont vérifiés, et le résultat compte pour votre classement.

    • Aucun avis
    • Intermédiaire
    • 2 h 50 min
    • 1 500 crédits
  • AvancéParcours : Linux : administration système, préparation au LFCS

    Linux : services systemd, timers et règles udev

    La douane écrit pour la troisième fois : plus aucune déclaration n'est arrivée au guichet unique depuis trois jours, et des conteneurs sont bloqués au port. Le même matin, le chef de quai signale que l'étiqueteuse n'imprime plus rien depuis que le poste a été rebranché. Au lab 1, vous aviez rangé le script de collecte dans la colonne des risques : lancé au démarrage par cron, détaché par nohup, sa sortie jetée dans /dev/null. Le risque s'est réalisé. Vous commencez par l'enquête : le journal qui s'arrête sans un mot, l'onduleur qui révèle que seules les coupures de courant relançaient la collecte, puis le script lancé à la main qui meurt sous vos yeux au premier refus du guichet. Avant de toucher à quoi que ce soit, vous mettez la configuration sous Git. Vous confiez ensuite la collecte à systemd : une unité qui la relance sans s'épuiser, sous son propre compte, avec une mémoire bornée et un journal où plus rien ne se perd. Le récapitulatif de nuit, que cron oubliait les nuits de coupure, devient un timer qui rattrape les passages manqués. Reste la douchette. Le noyau numérote les appareils dans l'ordre où ils arrivent, et le logiciel d'étiquetage écoute désormais le clavier. Vous lisez ce que le noyau et udev savent d'un appareil, vous croisez les modules qui le pilotent, et vous écrivez la règle udev qui le nomme par ce qu'il est, pas par son rang d'arrivée. Pour finir, un collègue « simplifie » la configuration un vendredi soir, et Git vous dit en dix secondes ce qui a changé. Le guichet des douanes et le matériel du quai sont simulés sur la machine, et se comportent comme les vrais. À la fin, l'état du serveur et votre historique Git sont vérifiés, et le résultat compte pour votre classement.

    • Aucun avis
    • Intermédiaire
    • 3 h
    • 1 500 crédits
  • AvancéParcours : Linux : administration système, préparation au LFCS

    Linux : centraliser les comptes avec LDAP, SSSD et PAM

    Le commissaire aux comptes est revenu. Au lab 2, vous aviez verrouillé le compte de ktraore, l'agent de quai parti depuis des mois. Son rapport préliminaire tient en une phrase : ktraore est verrouillé sur srv-erp, mais actif sur srv-quai, avec les droits d'administration, et l'auditeur s'y est connecté avec un mot de passe trouvé dans les notes de l'ancien prestataire. Le groupe a un annuaire central depuis l'an dernier, que personne n'a fini de raccorder. La contre-visite a lieu vendredi. Vous commencez par cartographier le parc : un même salarié qui porte deux numéros différents d'un serveur à l'autre, et un compte local qui hérite en silence des groupes de l'annuaire. Vous apprenez à lire un annuaire LDAP, ses branches, ses entrées et ses filtres, en chiffrant la connexion et en vous présentant avec un compte qui ne peut que lire. Puis vous désactivez l'ancien salarié dans l'annuaire, et vous découvrez que la révocation centrale ne vaut rien tant qu'un compte local porte le même nom. Le lab va là où s'arrêtent les tutoriels. Raccorder un serveur avec SSSD, NSS et PAM, et comprendre pourquoi SSSD refuse de démarrer avec un fichier lisible par tous. Migrer les comptes locaux vers l'annuaire sans qu'aucun fichier ne change de main, en sachant pourquoi un chown lancé sur tout le disque volerait leurs fichiers aux comptes d'un conteneur. Constater qu'un ordre mal choisi rouvre la porte qu'on croyait fermée. Couper l'annuaire, voir qui peut encore entrer grâce au cache, et tester le compte de secours avant d'en avoir besoin. Enfin, écrire la procédure de départ que l'auditeur lira vendredi. L'annuaire est un vrai OpenLDAP, et le serveur du quai un conteneur avec son propre SSSD : vous travaillez sur un petit parc, depuis un seul terminal. À la fin, de vraies tentatives de connexion vérifient vos révocations, comme le fera l'auditeur, et le résultat compte pour votre classement.

    • Aucun avis
    • Avancé
    • 3 h 15 min
    • 1 500 crédits