Autoblog de paulds.fr

OK, je l’ai encore fait, j’ai encore trollé… Samedi je disais sur Twitter que la porte de mes toilettes est décorée d’un panneau Epitech (c’est le cas, vous aurez une photo si vous êtes sages) et forcément dans la foulée j’ai reçu plusieurs mails me demandant pourquoi, ce que je reprochais à cette école et même un me demandant si il devait choisir une autre école finalement.

Alors je vous rassure : non je n’ai rien contre Epitech en soit, à vrai dire je m’en fiche…

Ce qui me gêne plus c’est le cursus général de l’informatique supérieure qui a tendance à former des bataillons de chefs de projet technico-fonctionnels (ce qui ne correspond pas au besoin du marché en passant hein !) et qui le fait par une pluie de connaissances dictées et normalisées par des années de recherches super intéressantes sur la théorie de la relativité du peut-être des besoins des entreprises pas représentatives du marché d’il y a 20 ans…

J’abuse : à la fin des études en général on met l’étudiant en stage pour qu’il voit comment ça se passe dans la vraie vie (qu’il réalise qu’il a payé 5 ans d’étude pour apprendre des conneries).

Gâchis extraordinaire s’il en est lorsque l’on sait qu’il y a un secteur du logiciel (au sens large) fondamental sur les interwebz et ailleurs qui manque toujours de ressources et qui est le plus formateur : l’open source.

Partant de là pourquoi ne pas ajouter un peu d’open source à ces études, pourquoi même ne pas calquer le déroulé pédagogique dessus ?

Coder pour les autres

L’un des intérêts principaux de cette proposition réside dans la rigueur et la qualité qui découle de projets voués à être diffusés de la sorte.

Il m’est arrivé de coder des trucs à l’arrache, sur le pouce, pour des besoins spécifiques personnels. A l’inverse lorsque j’ai fait des propositions de modification pour des fonctionnalités avancées de Prestashop (utilisé sur 100.000 boutiques à l’époque) j’ai pris plusieurs heures pour faire des vérifications dans tous les sens, des tests de régression, des vérifications sur l’environnement (mes modifications ne risquent-elles pas d’impacter des modules third-party ?)…

La qualité du code sortie est aussi beaucoup plus propre et on apprend à se servir d’outils assez formidables que jamais personne ne vous fera voir en école d’ingénieur actuellement (trouvez moi un cursus PHP avec du PHPCS, PHPMD, PHPUnit, …) pour valider son code de façon industrielle… Avouez que d’un coup ça donne une autre gueule aux TPs !

Travailler en équipe(s)

Puisque l’on parle d’outils justement, une des caractéristiques les plus intéressantes de l’open-source (vu sous cet angle de l’apprentissage) est sa capacité à réunir des dizaines de compétences autour d’un projet via des outils, des process, au delà souvent même de la barrière des langues. Ah oui parce que bon, les ingénieurs BAC+5 en informatique qui ne parlent pas anglais non plus ce n’est pas une réalité du marché…

J’ai vu des équipes en entreprise comme dans le monde de l’open-source essayer de trouver la meilleure suite d’outils pour communiquer, s’organiser, partager le code… A la sortie d’une école vous devriez maitriser les principaux et en connaitre quelques exotiques. Cette exhaustivité n’existe que dans le monde open-source. Dans le monde de l’entreprise (tu sais, ton stage de fin d’année) vous serez formé à une techno (SVN + Mantis + mail au hasard) et pas plus…

Toujours être à la pointe

Ah oui la veille… Bon on va pas se leurrer, si vous faites une école d’info normalement c’est pour être tranquille en émargeant à 50k€ en junior avec un CDI et des tickets resto…

Ou pas : normalement lorsque l’on arrive à ce niveau on est avant tout un passionné, quelqu’un qui veut chercher à connaitre plus que ce qu’il va utiliser potentiellement, chercher à comprendre comment fonctionne ce qu’il utilise au quotidien, découvrir de nouveaux outils lui permettant de travailler plus efficacement ou moins, …

Bref ça demande d’être capable de faire de la veille technologique, de savoir analyser un produit lorsqu’on le découvre et être capable de prendre une décision rapide sur son intérêt ou pas à l’intégrer dans tel ou tel projet.

Tout cela on peut savoir le faire de façon innée, on peut l’apprendre de façon théorique mais là encore il n’y a que dans l’open-source, avec ses collaborations de toutes part, que j’ai vu son efficacité atteindre son paroxysme. Il n’y a que dans l’open-source où j’ai vu des équipes s’organiser pour analyser l’existant concurrent, les autres produits éventuellement intégrables et prendre des décisions par rapport à tout ceci pour faire évoluer un produit sans pour autant s’astreindre à la durée d’un sprint scrum (private-troll !!!).

Contribuer à quelque chose (de grand)

Et pour finir, non sur le moins pire (last but not least quoi), le monde de l’open-source est très ouvert : vous pouvez demain contribuer à un projet qui a déjà des centaines de milliers d’utilisateurs. Sur le principe c’est génial pour tous les points évoqués plus haut et pour le produit et ses utilisateurs en eux-même à qui vous avez probablement rendu service en contribuant à la réussite dudit projet.

Mais il y a un autre point intéressant à cela : le CV. Un recruteur préférera (théoriquement hein, si vous postulez chez Crosoft ça marche plus… mais si c’est le cas quittez ce blog) voir des noms de gros et / ou beaux projets tout au long de votre cursus universitaire (voire avant et après dans l’idéal) que vos trois mois de stages à la DSI de Leclerc Bourgogne (comme pour Epitech, rien contre eux).