Article initialement posté sur notnil.org, le blog perso de matthieu
Prélude
Ce qui va suivre est un début de réflexion globale sur la gestion des compétences en informatique à l'heure du tout cloud, qu'elles soient individuelles ou collectives, à l'échelle d'une entreprise, voire d'un pays.
Le fameux "projet perso"
Je rencontre en recrutement environ 1 dev junior par semaine, de toute type de formation : école d'ingé, DUT/BUT, formation courte, bootcamp voire autodidacte.
Sur ce type de profil, nous sommes évidemment intéressés par les projets réalisés par le candidat, et a fortiori par les projets développés sur temps libre qui permettent très souvent de mieux qualifier le candidat, ses compétences, attentes et leviers.
Sur les 50% présentant un projet personnel, environ 30% poussent le sujet au bout et déploient sur un environnement de production celui-ci, et à de très (très) rares exceptions près, toujours sur un cloud provider comme Netlify, Heroku, Vercel, AWS, ou encore GCP.
YAML Powa
[DISCLAIMER pour la suite] Je ne juge absolument pas de l'intérêt de déployer sur un cloud, et des avantages indéniables qu'une infra cloud procure. Mon point va porter uniquement sur les compétences développées.
"Et donc, j'ai mis en production le projet sur Netlify !", le candidat généralement est plutôt fier de montrer son projet qui tourne SUR INTERNET \o/.
C'est top, ça fonctionne et c'est hyper gratifiant d'avoir sa propre création, son bébé, présentable à ses parents/amis/gentils-recruteurs sans un
localhost:8080.Mais comment donc déployer sur un cloud ? C'est plutôt très simple, très bien documenté et accessible à n'importe qui, a priori pour un jeune développeur logiciel. Evidemment chaque provider dispose de ses propres processus, systèmes de configuration, UI, CLI, qui permettent de transformer des lignes de codes sur Git en projet de production, souvent gratuitement ("There ain't no such thing as a free lunch"-TANSTAAFL).
Un fichier de config en YAML, une clef d'API, un
git remote add, un set de variables d'environnement, et c'est parti.Qu'est ce que notre jeune développeur, peut-être spécialisé en python ou JS, a appris de cette opération ? Quelles compétences ? Le format YAML ? Une nouvelle commande GIT ? Le principe d'authentification par clefs d'API ? Le concept de PaaS ? L'informaticien a certainement appris toutes ces notions et compétences, et le professionnel a appris à utiliser UN cloud.
DIY
Maintenant, imaginons le même projet personnel mais sans cloud provider. Comment déployer son projet? Quelles tâches va-t-il devoir réaliser pour atteindre cet objectif ? On peut citer en vrac (non exhaustif) :
- louer un server ou un VPS
- sécuriser son accès (ssh, firewall, fail2ban)
- déployer un serveur http
- déployer son code
- configurer le routage
Evidemment, il doit y avoir (facilement) un *10 sur le temps de mise en place de cette solution comparée à la version cloud, sans compter l'absence de scalabilité et de résilience.
Regardons maintenant les compétences que notre novice va développer :
- architecture gnu/linux, gestion des utilisateurs, gestion des droits d'accès
- configuration ssh, principe de chiffrement asymétrique, génération de clefs, concept du firewall, gestion de flux réseaux
- serveur HTTP, sécurisation SSL
- déploiement d'un Nginx, Apache ou Caddy, paramétrage des vhost, génération et gestion des certificats
- redirection DNS
- build d'une application
On m'objectera évidemment dans cet exemple que "Ce n'est pas le job d'un dev de déployer une app en prod" : dans la majorité des cas en grandes entreprises, en effet. Néanmoins, on imagine pas le nombre de dev "ninja JS" (#privatejokede2015) qui ignorent complètement des pans entiers de l'informatique, avec sans doutes des répercussions sur leur production, comme la sécu (posez la question à des devs de 2/3 ans d'expérience sur le contenu d'une requête HTTP, vous pourriez avoir des surprises).
Je ne sais pas vous, mais je trouve que cet apport de compétence est indispensable, surtout en début de carrière. Oui, c'est long, oui, ça peut etre pénible, mais le nombre de concepts clefs qui sont balayés fait que cet apport est inestimable. Celui-ci profite à la fois au professionnel, qui devient polyvalent, et à l'informaticien qui va pouvoir améliorer la qualité de sa production.
Déployer une app sur un serveur permet d'aborder des concepts qui ne sont qu'effleurés dans la solution cloud -je ne parle que de déployer une app simple d'un dev junior hein-, et qui sont évidemment cruciaux sur la compréhension de l'environnement informatique.
Le Professionnel et l'Informaticien
Ok, ce que j'ai écrit est plutôt évident, alors pourquoi l'ai-je fait ?
Avant tout, je pense qu'il faut marteler aux jeunes ingé/devs de comprendre ce qui se passe sous le capot. Les niveaux d'abstractions, quelle que soit la discipline, peuvent être très élevés, et comprendre "ce qui se passe" va faire la différence entre 2 personnes. C'est le cas avec une personne qui a poussé la curiosité à prendre son propre serveur (quelques euros par mois pour un VPS) pour héberger ses projets.
Dans le cas de l'utilisation d'un cloud, la personne a appris à utiliser et à configurer UN cloud provider. C'est une compétence intéressante, qu'il va pouvoir valoriser ($$$) professionnellement assez facilement en fonction des providers. Il pourra même, pour certains, passer des certifications (coucou AWS & GCP) qui le rendront bankable pour travailler sur des infrastructures implémentées sur ce même provider.
Le professionnel a développé des compétences valorisables sur le marché, mais l'informaticien a développé des compétences assez faiblardes. En revanche, ce dernier s'est affranchi de problèmes vieux comme l'informatique (scalabilité, résilience, sécurité, etc). Il a profité des compétences de milliers d'informaticiens qui ont permis ce bijou d'ingénierie avec à la clef la diminution du temps et des coûts de mise en production, comparable à l'effet d'expérience dans l'industrie.
La face cachée, c'est que le professionnel s'est "lié contractuellement" à un cloud provider et l'informaticien s'est créé une dépendance. C'est d'ailleurs là un coup de génie pour le provider, car, que va proposer comme solution l'informaticien certifié "cloud architect AWS" à une problématique ? Evidemment une solution AWS, même si celle ci ne répond pas totalement au besoin, ou complexifie la solution (sans même parler de la dépendance totale à ce provider). Monter des certifications sur ses produits, c'est se créer des ingénieurs commerciaux "under cover" qui vont générer du CA.
Ce sont ces derniers points qui m'inquietent le plus. Sans être un libriste-forcenné-à-bas-les-GAFAM, les gains de productivité créés par l'utilisation des produits des grands cloud providers, leur facilité, s'accompagne d'une perte globale de compétences, au niveau individel ET collectif.
Pourquoi collectif ? Car le "sans serveur" me fait furieusement penser au "sans usine" d'il y a 30/40 ans et que, pour nous, français, ça ne s'est pas très bien terminé.
Fin de la première partie
