Doom Eternal: aussi bon que frustrant

Rédigé par uTux - - Aucun commentaire

J'ai bien aimé Doom 2016, un jeu bien bourrin offrant des mécaniques proches de celles des fps à l'ancienne, servi avec une ost Metal presque parfaite. Aujourd'hui nous sommes en 2020 et sa suite Doom Eternal est sortie. Le titre est bien trouvé, Doom est en effet éternel et tout comme Star Wars il transcende les générations.

L'éditeur Bethesda a orienté la communication du jeu sur le personnage principal: le Doom guy (appelé ici Doom Slayer) qui est totalement bourrin et qui met les pieds où il veut, surtout dans la gueule des démons. Aussi fort que Chuck Norris, il compte bien sauver le monde à lui tout seul en exterminant tout l'enfer sur son chemin. Le message est clair, pas question de réfléchir ou de faire dans la subtilité, on va user d'un arsenal démesuré pour poutrer les méchants. Il faut ajouter à cela l'OST monumentale de Mick Gordon qui revient pour nous prouver que Doom est la symbiose du jeu vidéo et du Metal. On espère donc que le jeu est à la hauteur des promesses de la communication de Bestheda.

Doom eternal

J'ai donc acheté Doom Eternal et fait exploser ma fibre optique pour le télécharger. Comme vous pouvez le voir, l'internet français n'est pas si saturé que cela, à moins que les FAI fassent de la QoS pour nous permettre de télécharger Doom à pleine vitesse, ce qui serait vraiment royal :

Vive la fibre

La technique

S'il y a un point sur lequel Doom Eternal fait un sans-faute, c'est la technique. Les graphismes sont très réussis et le jeu est extrêmement fluide sur à peu près toutes les configurations. Par exemple ma GTX 1070 qui date de 2017 le supporte en 2560x1440 Ultra sans broncher. Le jeu est une vitrine technologique pour l'api Vulkan et frappe un grand coup. Si on ajoute à cela les temps de chargement qui se comptent en secondes, on a probablement affaire à l'un des jeux AAA les mieux optimisés de tous les temps. C'est dit.

Le gameplay

Doom Eternal mérite clairement son succès. Les développeurs du jeu se sont vraiment demandé comment améliorer les mécaniques de fps à l'ancienne sans en renier les fondements. Et pour cela ils ont rendu le jeu beaucoup plus nerveux (encore) et ajouté de nombreux moyens d'éliminer les ceux qui se dressent sur notre chemin. D'une part les ennemis et leurs projectiles sont plus rapides, ce qui fait que vous allez subir beaucoup de dégâts même en strafant, et d'autre part les item à ramasser sont beaucoup plus rares. Pour survivre il faut donc aller tuer les monstres au corps à corps, ce qui génère des bonus. Je n'en suis qu'à 2h de jeu mais il y a déjà :

  • Les glorykill qui donnent des points de vie.
  • La tronçonneuse qui donne des munitions.
  • Le lance-flammes qui donne de l'armure.

Cette incitation à aller au corps à corps est à double tranchant, elle rend indéniablement le jeu plus violent et plus technique, mais elle peut être frustrante parce qu'on ne peut plus se contenter de tirer en continu avec le Gatling Gun sans se poser de question, les munitions sont trop rares. J'ai eu beaucoup de mal à m'y faire.

Ces ajouts de mécaniques de gameplay peuvent aussi être déroutants au début du jeu car il y a beaucoup beaucoup de choses et elles arrivent trop vite. En 2h de jeu j'ai déjà : les glorykill, tronçonneuse, lance-flammes, tirs secondaires, améliorations d'armes, améliorations d'armure praetor, les cellules sentinelle, la frappe sanglante, le dash, le ralenti, les portes du Slayer... j'ai souvent eu envie de crier stop !!!

Un autre ajout important est l'agilité de votre personnage. Il est maintenant possible d'escalader les murs et d'utiliser des barres d'acrobate et les dashs pour aller plus loin. Le jeu tire pleinement parti des 3 dimensions, peut-être parfois à l'extrême avec des phases de plateforme/puzzle qui cassent le rythme et peuvent être frustrantes.

En parlant de casser le rythme, le jeu dispose maintenant d'un hub, c'est à dire que le Doom Slayer a une base qu'il rejoint entre chaque mission, et qui permet de visualiser les secrets collectés, s’entraîner, débloquer des améliorations, lancer les missions. Je ne suis pas du tout fan du hub, je ne comprends pas pourquoi le jeu n'enchaîne tout simplement pas les niveaux comme dans Doom 2016.

Pour en finir avec les points négatifs, Doom Eternal a beaucoup trop de phases qui ne servent à rien d'autre qu'expliquer l'histoire du jeu. Et il y a à mon sens beaucoup trop d'histoire...

Conclusion

Doom Eternal est un excellent jeu qui a su se renouveler et faire évoluer les mécaniques de gameplay du fps à l'ancienne sans les dénaturer. Et pourtant, il est indéniablement entaché de nombreuses lourdeurs qui pourront rebuter certains joueurs et le rendre aussi frustrant que bon. Si vous hésitez, attendez que le prix baisse.

Avec un peu plus de munitions, un système de sauvegarde rapide et en l'absence du hub, j'aurais encore plus apprécié le jeu. En attendant, il est toujours possible de jouer aux Doom originaux grâce à Doomsday ou GZDoom, ou encore d'aller à la concurrence avec eDuke32. Je lâche quand même mon Seal of Approval à Doom Eternal.

SOA

Comparons Kubernetes et Swarm

Rédigé par uTux - - Aucun commentaire

Attention, cet article va exploser le compteur de buzzwords.

J'utilise Docker en standalone depuis bientôt 3 ans, d'ailleurs mon blog tourne dessus à l'aide de deux images : PluXml et OpenSMTPD - pour le formulaire de contact - que j'ai moi-même réalisé. Sans dire que je maîtrise Docker, j'ai un niveau bien avancé. A côté de cela je travaille régulièrement avec OpenShift (la distribution Kubernetes commerciale de Red Hat) et même si je suis bien moins à l'aise qu'avec Docker, j'ai tout de même pas mal de connaissances.

Docker seul est un peu limité, on ne peut pas faire de clustering, ce qui est bien dommage car les containers et les micro-services s'y prêtent fortement. Il existe heureusement Swarm qui étend Docker au support d'une infrastructure à plusieurs nœuds.

D'un autre côté, le monde entier a les yeux rivés sur Kubernetes, le grand concurrent à Docker conçu dès le départ pour les clusters et la haute disponibilité. Ce dernier est très puissant mais aussi beaucoup plus complexe que Docker Swarm (surtout les RBAC dont je ne parlerai pas). Il faut aussi comprendre qu'on ne télécharge pas Kubernetes, on télécharge une distribution Kubernetes, et il en existe plusieurs. Dans le test de performances plus bas dans cet article je vais utiliser k3s, fourni par Rancher et grandement allégé et simplifié.

Alors, faut-il utiliser Swarm ou Kubernetes ?

Architecture

Docker Swarm

Le cluster se compose de nodes manager et workers. Les premiers sont chargés de piloter le cluster, les second exécutent les containers. Les commandes doivent être exécutées sur un des managers. Un système d'encapsulation UDP est en place entre les nodes, il permet aux réseaux des containers de se propager.

Swarm Diagram
Image provenant de la documentation Swarm.

Dans Swarm on déclare des services, soit en cli soit en yaml (docker-compose). Le scheduler va ensuite provisionner les containers nécessaires au service sur un ou plusieurs workers, selon le nombre de replica demandé. Exemple :

$ docker service ls
ID             NAME        MODE         REPLICAS   IMAGE          PORTS
sb40x4z1zqkb   httpd       replicated   1/1        httpd:latest   
owq6yurtagjg   traefik     replicated   1/1        traefik:2.1    *:80->80/tcp, *:443->443/tcp

On peut augmenter ou diminuer manuellement le nombre de replicas, il y a un load balancer interne qui va répartir le trafic de manière transparente. Un système d'affinités permet de lier les containers à une node en particulier, très pratique. Les services peuvent être mis à jour en rolling update, c'est à dire qu'on ne restart pas tous les containers d'un coup mais les uns après les autres, ce qui permet de ne pas interrompre le service. Un rollback est possible.

Et... c'est à peu près tout. Simple et efficace, mais aussi un peu limité il faut l'avouer. Swarm est un bon choix pour un usage personnel de part sa simplcité. Par contre on va voir que pour les cas d'usage avancés, Kubernetes est plus adapté.

Kubernetes

Accrochez-vous. Commençons avec l'architecture Infra.

Le cluster est composé de nodes Control Plane (les masters ou managers) ainsi que des workers. Les Control Planes pilotent le cluster et l'API Kubernetes, à l'aide d'un système de configuration centralisé, qui est souvent basé sur etcd (selon les distributions) mais pas toujours. Par exemple, k3s utilise sqlite. Les workers ont un agent (kubelet) qui reçoit les instructions du scheduler. Là encore une encapsulation UDP est prévue entre les nodes pour permettre la propagation des réseaux des containers.

Swarm Kubernetes
Image provenant de la documentation Kubernetes.

Attaquons maintenant le fonctionnement des ressources. Dans le cluster Kubernetes, tout est objet, tout est yaml ou json. C'est avec ça que l'on contrôle comment nos containers sont déployés et fonctionnent. Les types (kind) d'objets les plus courants sont :

  • Pod : Un espace logique qui exécute un ou plusieurs containers.
  • Service : Sert à exposer un ou plusieurs ports pour un pod, attaché à une IP privée ou publique.
  • DeploymentConfig : Défini ce qu'on déploie. Typiquement l'image à utiliser, le nombre de replica, les services à exposer, les volumes...
  • ReplicaSet : un contrôleur qui va vérifier que le nombre de pods en place correspond au nombre de replicas attendu. Scaling automatique possible.
  • PV, PVC : système d'attribution (automatique ou pas) de volumes persistants.
  • ConfigMap : objet permettant de stocker de la configuration, qui peut être ensuite lue et utilisée par les containers.
  • Namespace : Séparation logique des ressources, seules les ressources affectées au namespace en cours sont visibles.

Exemple d'utilisation :

$ kubectl -n web get all
NAME                          READY   STATUS    RESTARTS   AGE
pod/svclb-httpd-rw7k5        1/1     Running   0          5s
pod/httpd-8647457dd7-s2j4d   1/1     Running   0          5s

NAME             TYPE           CLUSTER-IP     EXTERNAL-IP   PORT(S)        AGE
service/httpd   LoadBalancer   10.43.80.117   10.19.2.73    80:30148/TCP   5s

NAME                          DESIRED   CURRENT   READY   UP-TO-DATE   AVAILABLE   NODE SELECTOR   AGE
daemonset.apps/svclb-httpd   1         1         1       1            1                     5s

NAME                     READY   UP-TO-DATE   AVAILABLE   AGE
deployment.apps/httpd   1/1     1            1           5s

NAME                                DESIRED   CURRENT   READY   AGE
replicaset.apps/httpd-8647457dd7   1         1         1       5s

Par souci de simplification je ne parle pas du système de RBAC qui permet une granularité dans la gestion des droits, au prix d'une complexité (très) importante.

Kubernetes n'est pas aussi simple que Swarm mais il permet de faire beaucoup plus de choses. En fait on peut presque dire qu'on peut tout faire avec. Les namespaces sont une fonctionalité très pratique, tout comme le scaling auto et la possibilité d'éditer les objets avec la commande edit. En environnement pro, où vous allez gérer plusieurs clients, beaucoup d'applications et de fortes charges, Kubernetes est quasiment indispensable.

Fonctionnalités

Swarm Kubernetes
Configuration yaml ou json
Oui Oui
Commandes Docker
Oui Non
CLI distant
Oui Oui
Network inter-containers & DNS
Oui Oui
Replicas Oui Oui
Scaling manuel Oui Oui
Auto-scaling Non Oui
Health probes
Non Oui
Modification d'objets en ligne
Non Oui
RBAC Oui (EE) Oui
Namespaces Non Oui
Volumes self-service
Non Oui

Kubernetes est indéniablement plus complet, mais à quel point ces fonctionnalités sont-elles indispensables, surtout pour un usage en perso ? Et bien il y a à mon sens deux points que je trouve excellents dans Kubernetes et qui me manquent dans Swarm:

  • La modification d'objets en ligne. J'entends par là que la commande kubectl edit type/object permet de faire une modification à la volée, par exemple changer un port ou une version d'image dans un DeploymentConfig. Cela n'est à ma connaissance pas possible dans Docker, sauf avec docker-compose (stack dans le cas de Swarm) à condition d'avoir encore les fichiers yaml et que ceux-ci soient à jour.
  • Les namespaces. Pour éviter de mélanger plusieurs ressources de projets qui n'ont rien à voir, Kubernetes propose un système de namespaces. Par exemple je peux créer un namespace utux dans lequel je vais déployer mes images PluXml et OpenSMTPD, ce qui permet de s'y retrouver mais aussi de tout supprimer plus facilement si besoin. Les namespaces sont aussi très utiles lorsque vous partagez ou louez votre Cluster Kubernetes, chaque utilisateur a ainsi son espace dans lequel il ne voit que ses ressources.

Cependant Docker et Docker Swarm sont beaucoup plus simples et n'utilisent que des composant upstream.

Consommation de ressources

Tests effectués sur des instances DEV-1S de chez Scaleway (2 vcpu, 2GiB RAM, no swap). Le système d'Exploitation est Debian 10 Buster x86_64.

  • Système seul: RAM 70.9M/1.94G
  • Swarm seul: RAM 155M/1.94G
  • Swarm + Traefik + PluXml (apache): 209M/1.94G
  • k3s seul: RAM 619M/1.94G
  • k3s + Traefik + PluXml (apache): 678M/1.94G
RAM à vide

Si vous comptez monter un cluster de Raspberry Pi avec 1GB de mémoire, vous pouvez oublier k3s/Kubernetes qui en consomme déjà presque 75% à vide. Si vous avez les moyens de payer des serveurs de calcul un peu plus costauds, avec 16 ou 32GB de mémoire, la différence sera alors négligeable.

Les pré requis pour certaines distributions comme OpenShift sont beaucoup plus importants: 4 vcpus et 16GiB de ram pour chaque master (x3), 2 vpus et 8GiB de ram pour les workers (à multiplier par 4 si vous montez l'infra de logging ElasticSearch). C'est la raison pour laquelle je ne l'ai pas utilisé dans ce comparatif, il est hors compétition.

Exemple

Docker Swarm

Exemple simple avec la création d'un container apache vide :

version: '3'

services:

  web:
    image:
      httpd:latest
    ports:
      - 8080:80
 

Création :

$ docker stack deploy -c web.yaml test

Vérifications :

$ docker service ls
ID            NAME        MODE        REPLICAS    IMAGE         PORTS
8pxc580r3yh6  test_web    replicated  1/1         httpd:latest  *:8080->80/tcp

$ curl http://127.0.0.1:8080
<html><body><h1>It works!</h1></body></html>

Kubernetes

Reprenons notre container apache vide :

apiVersion: v1
kind: Service
metadata:
  name: web
  labels:
    app: web
spec:
  ports:
    - port: 80
  selector:
    app: web
    tier: frontend
  type: LoadBalancer
---
apiVersion: apps/v1 # 
kind: Deployment
metadata:
  name: web
  labels:
    app: web
spec:
  selector:
    matchLabels:
      app: web
      tier: frontend
  strategy:
    type: Recreate
  template:
    metadata:
      labels:
        app: web
        tier: frontend
    spec:
      containers:
      - image: httpd:latest
        name: web
        ports:
        - containerPort: 80
          name: web

Chargons ces objets :

$ kubectl create namespace test
$ kubectl -n test create -f web.yaml

Vérifions :

# kubectl -n test get all
NAME                       READY   STATUS    RESTARTS   AGE
pod/svclb-web-jqs6j        0/1     Pending   0          7m17s
pod/web-774f857549-dstkz   1/1     Running   0          7m17s

NAME          TYPE           CLUSTER-IP     EXTERNAL-IP   PORT(S)        AGE
service/web   LoadBalancer   10.43.109.52        80:30452/TCP   7m17s

NAME                       DESIRED   CURRENT   READY   UP-TO-DATE   AVAILABLE   NODE SELECTOR   AGE
daemonset.apps/svclb-web   1         1         0       1            0                     7m17s

NAME                  READY   UP-TO-DATE   AVAILABLE   AGE
deployment.apps/web   1/1     1            1           7m17s

NAME                             DESIRED   CURRENT   READY   AGE
replicaset.apps/web-774f857549   1         1         1       7m17s

$ curl http://10.43.109.52
<html><body><h1>It works!</h1></body></html>

Conclusion

Kubernetes est plus complet que Swarm mais aussi plus compliqué. Il n'est pas toujours facile de choisir entre les deux, mais je vous donne les conseils suivants :

  • Pour un usage personnel, Docker standalone ou Docker Swarm sera votre choix par défaut, même si rien ne vous empêche d'essayer Kubernetes :)
  • Si vous êtes pragmatique ou que vous souhaitez travailler sur les containers, alors ce sera Kubernetes. C'est l'outil en vogue plébiscité par tout le monde et c'est ce que vous devez avoir sur votre CV.
  • Pour un usage en entreprise, Kubernetes sera incontournable car il y a de nombreuses offres dans le Cloud et On-Premise. Aks ou OpenShift sur Azure, Eks chez Aws, pour ne citer que les plus connus. Tout l'écosystème des containers est focalisé sur Kubernetes et les namespaces vous serons indispensables dans un contexte multi-client.

Pour finir, un court retour d'expérience sur l'utilisation de Kubernetes en entreprise. Tout d'abord, soyez conscient que votre cluster, vos clients et vos utilisateurs vous poseront de nombreux défis. Ne pensez pas que Kubernetes va résoudre magiquement tous vos problèmes et que vos admins vont se tourner les pouces, bien au contraire. Dans le cas d'une plateforme On-Premise, prévoyez 2 admins à temps plein au minimum. Ensuite, vous devez disposer de compétences dans quasiment tous les domaines : réseau, stockage, système, middlewares et surtout avoir une bonne maitrîse de la Elastic Stack (ELK ou EFK) puisque vous aurez à gérer les logs de vos nodes et containers.

Avec cet article j'espère avoir bien présenté les différences entre Docker Swarm et Kubernetes et fourni quelques pistes à ceux qui hésitent :)

Maître de stage - Episode 2: L'arrivée

Rédigé par uTux - - 4 commentaires

Billet précédent: Maître de stage - Episode 1: Recrutement.

Comme c'est ma première expérience de maître de stage, je veux que tout soit parfait. Aussi pour préparer l'arrivée de mon stagiaire, j'ai concentré mon attention sur trois points :

  • Préparer l'arrivée dans l'entreprise (avoir un compte A.D et obtenir un PC).
  • Trouver un sujet de stage.
  • Lister les compétences à valider durant le stage.

Les formalités sont assez simples, quelques formulaires à remplir et coups de fil à passer. En revanche, pour le sujet de stage, c'est un peu plus complexe. En effet je voulais un sujet qui réponde aux critères suivants :

  • Pas trop simple. Mon stagiaire est un futur ingénieur, il ne faut pas qu'il s'ennuie dans des tâches peu gratifiantes et inutiles.
  • Pas trop compliqué. Il n'a pas beaucoup d'expérience et ne sera là que 6 mois. De plus il faut que moi-même je maîtrise le sujet afin de l'accompagner.
  • Faire appel à de multiples compétences. Il n'y a pas que la technique, l'ingénieur est amené à rechercher des solutions aux problèmes, rédiger des DAT (Dossier Technique d'Architecture), participer aux réunions avec les architectes, éventuellement faire un peu de gestion de projet.
  • Être bien défini et collaboratif. Le sujet doit tenir sur 6 mois, et nous devons être capables de reprendre le travail produit quand il sera parti.
  • Éviter de divulguer des informations sensibles. Le stagiaire a signé les accords de confidentialité, aucun problème avec ça, en revanche son rapport de stage sera amené à circuler à l'extérieur de l'entreprise. Il faut donc éviter d'y mentionner les secrets de fabrication :)

J'ai donc listé quelques sujets possibles pour en discuter avec lui le moment venu.

A côté de cela, j'ai également prévu un système d'entretiens mensuels et d'objectifs additionnels. Par exemple participer à la rédaction d'un DAT ou se préparer à la certification AZ-103. Ces objectifs ne sont pas obligatoires pour la réussite du stage mais constituent un plus sur son CV surtout s'il veut continuer à travailler dans ce domaine.

L'épisode 3 parlera des débuts du stage avec les imprévus dus au Coronavirus.

Maître de stage - Episode 1: Recrutement

Rédigé par uTux - - Aucun commentaire

Billet précédent: Maître de stage - Episode 0: Les origines.

La première étape est donc le recrutement. Il se déroule ainsi :

  • Trouver un sujets de stage, au moins savoir de quoi ça va parler. Ce n'est pas forcément évident car cette étape se déroule plusieurs mois avant le stage, on ne sait pas forcément sur quoi on va travailler et quels projets vont se présenter. Le sujet global que je propose est le Cloud Public Azure / AWS.
  • Définir une fiche de poste, qui énonce le profil recherché (stage de fin d'études pour un bac +5) et les technologies sur lesquelles l'étudiant sera amené à travailler. Une présentation de l'entreprise et de ce que fait notre équipe est également requise.
  • Éplucher les candidatures et les CVs.
  • Faire passer les entretients.
  • Retenir un candidat...

Je n'avais jamais fait l'exercice d'être du côté recruteur, c'est étonnant, je comprends maintenant la difficulté de cerner un candidat rien qu'en lisant son parcours sur une feuille A4. Je ne voulais pas être "le mauvais recruteur qui met injustement les CVs à la poubelle" mais je devais quand même trouver des critères objectifs et justes, tout en ayant conscience qu'un stagiaire est un stagiaire, il n'aura que très peu des compétences techniques recherchées. Accessoirement j'ai ressenti un petit "coup de vieux" en voyant les dates de naissance (1997)...

Passons maintenant à l'entretien. J'ai en fait des dizaines voire plus dans ma vie, toujours du côté candidat et je connais bien les règles du jeu. Apprendre à se présenter, à détailler son parcours, expliquer ce qui nous motive, parfois donner les réponses que le recruteur veut entendre (des défauts qui sont en fait des qualités), bla bla bla. Mais cette fois-ci j'étais de l'autre côté de la table, celui du recruteur. Et tout à coup c'était à moi de mener l'entretien, lancer les sujets, poser des questions constructives pour inciter le candidat à parler de lui. Heureusement mon chef m'a beaucoup aidé et est venu au premier entretien. J'ai retenu la formule suivante :

  1. Demander au candidat de se présenter, noter certains mots clés.
  2. Présenter l'entreprise, présenter notre métier, ce qui est attendu du candidat.
  3. Phase d'échange où on réutilise les mots clés pour interroger le candidat (hm, tu as fait un stage dans une entreprise qui fait de l'hébergement web, est-ce qu'il y avait de la HA ? De la virtu ? etc...). On répond aussi aux questions de ce dernier.
  4. On évoque les hobbies surtout les jeux vidéo ou la bidouille informatique, ça détend et parfois le candidat nous apprend des choses supplémentaires.
  5. Évoquer les modalités (salaire, horaires, transports...).

Dans un CV étudiant, les stages passés ont des sujets très variés voir radicalement différents, donc il n'est pas facile de trouver le fil rouge. Il faut essayer de comprendre les sujets qui ont été traités, les compétences mises en jeu, et ce que le candidat a appris. Je l'interroge sur sa culture informatique, s'il bidouille sur son temps perso, etc. Et bien sûr on juge le savoir-être, notamment la manière de s'exprimer, la politesse, on cherche à savoir si le sujet l'intéresse vraiment.

Après l'entretien arrive le débriefing en interne. Le candidat ne peut pas correspondre à 100% aux attentes, on essaie donc de juger s'il sera apte et suffisamment motivé pour le stage, en se rappelant encore une fois que c'est un étudiant. Finalement, nous avons dit oui, son savoir-être a beaucoup joué même si les compétences pouvaient paraître un peu faibles.

De manière humble je dois avouer que cette expérience, qui m'a placé du côté du recruteur, m'a appris beaucoup de choses. J'ai du mettre des mots sur ce que je fais chaque jour dans mon métier, apprendre à analyser les candidatures, construire un entretien qui mette le candidat à l'aise, et essayer de concilier l'aspect humain et rationnel. Je sens peser la triple responsabilité de choisir le bon candidat pour l'entreprise, pour moi, et pour lui-même. Je suis clairement sorti de ma zone de confort, de la technique, et ce n'est que le début.

L'épisode 2 parlera des préparatifs et de l'arrivée du stagiaire.

Maître de stage - Episode 0: Les origines

Rédigé par uTux - - 1 commentaire

A 32 ans, j'accueille mon premier stagiaire. J'avais cette idée en tête depuis quelques années déjà, mais je n'étais pas dans la bonne entreprise ou pas suffisamment "posé" pour me lancer dans l'aventure. C'est maintenant chose faite. Je vais essayer de tenir une série de billets dans lequel je décris cette expérience.

J'aime mon métier et j'ai envie de le transmettre, de former quelqu'un, le motiver, l'encourager si c'est la voie qu'il veut suivre. En même temps j'ai conscience des risques, un stage ou un contrat pro qui se passe mal peut casser un projet ou démotiver l'étudiant à travailler dans ce domaine. C'est ce qui m'est arrivé quand j'ai fait mon BTS, erreur de casting pour le stage, suivi de "la crise" en 2008, résultat j'ai totalement abandonné le domaine en question pour me "reconvertir" dans l'informatique mais tout en bas de l'échelle. Au final ce fut une bonne chose mais j'ai l'impression d'avoir perdu plusieurs années dans ma carrière professionnelle. Je dois maintenant faire mon maximum pour recruter la bonne personne et le faire monter en compétences, lui confier des sujets ni trop faciles ni trop difficiles, varier les domaines (architecture, réseau, projet...) juste assez pour que les 6 mois de stage le motivent à continuer !

Lorsque j'ai présenté l'idée à mon équipe et à mon chef, les réactions ont été positives mais on m'a averti qu'un stagiaire demande beaucoup de temps. J'ai compris que j'allais devoir améliorer mon organisation et potentiellement voir augmenter ma charge de travail, mais j'ai quand même envie de tenter le coup.

L'épisode 1 parlera du recrutement.

Fil RSS des articles