Quel langage pour développer demain ?

Au Spot Bouygues, je suis en contact en permanence avec des étudiants pour faire de l’Open Innovation. Le fossé est grand entre le fonctionnement de l’entreprise et celui des étudiants. Et il y a un domaine où la comparaison entre l’entreprise et les étudiants est intéressant c’est celui des plateformes de développement.

En effet, il est parfois étonnant de constater à quel point les langages utilisés par les étudiants sont souvent éloignés de ce que l’on connait en entreprise. Comme vous êtes nombreux à me poser la question des outils qu’utilisent les étudiants, je vous propose dans cet article une petite synthèse de ce que je vois au quotidien.

Précisons que cette synthèse s’appuie sur une observation du choix des étudiants sur les projets « libres »: c’est-à-dire ceux ou ni l’école ni moi n’imposons une technologie spécifique. Bref : quand ils peuvent utiliser la technologie qu’ils veulent.

Architecture 3 couches

Sans grande surprise, l’architecture choisie par les étudiants est une architecture à trois niveaux :

⇒ Base de données ;
⇒ Couche de service, backend ;
⇒ Couche de présentation, frontend.

Base de données : No SQL !

Si en entreprise on trouve plus facilement des bases de données SQL de type SQL Server ou Oracle, la base de données la plus utilisée sur les projets des étudiants est incontestablement MongoDB. Ce n’est pas forcément un choix réfléchi par rapport aux mérites du NoSQL vs SQL mais c’est tout simplement plus facile: pas de schéma à imaginer, facilité d’utilisation du JSON, simplicité d’installation, gratuité, …

En fréquence d’utilisation par les étudiants, viennent ensuite loin derrière, PostgreSQL et, plus rarement MySQL. Et ces bases sont souvent utilisées par les étudiants dans le cas où l’école impose un support multiDB.

REST pour longtemps

Pour ce qui est de la couche de services, le backend est systématiquement constitué par des services REST. Je n’ai jamais entendu parler de Web Services SOAP qu’on trouve pourtant encore beaucoup en entreprise.
La gestion d’authentification sur l’API REST se fait généralement de manière « propre » – l’EPITECH leur apprend très tôt les problèmes de sécurité 🙂 – en utilisant des tokens qui sont générés lors du login et véhiculé d’une requête à l’autre sur l’API.

Le langage de développement utilisé pour le backend est très souvent du node.js. Il est régulièrement associé à un framework de type Express, ou un « ORM » type Mongoose.

Je vois aussi de plus en plus souvent le langage Go utilisé sur la partie backend. Ses performances sont souvent mises en avant par les étudiants même si cela est rarement un impératif dans leur projet.

Le langage PHP reste présent, notamment associé au framework Symfony (http://symfony.com/) qui est pas mal utilisé sur l’école et facilite la génération d’une API.

De manière plus anecdotique, je rencontre aussi du Ruby on Rails ou du Python avec le framework Django. Il m’est arrivé une seul fois d’avoir un groupe d’étudiants ayant réalisé leur backend en .NET ! Je n’ai pas manqué de les féliciter d’être déjà « Entreprise Ready » ! Je n’ai jamais vu de projets d’étudiants avec un backend en J2EE 😉

Inutile de dire que 100% du backend utilisé par les étudiants s’exécute sur Linux. Beaucoup de groupe mettent en place de véritables infrastructures de déploiement en s’appuyant sur des containers Docker. Sinon, pour le serveur Web, on trouve plus souvent du Nginx que du Apache.

AngularJS est dans le coin

Pour la réalisation du FrontEnd web des applications, AngularJS, le framework de Google, fait clairement l’unanimité. Il est rare de trouver des projets où il n’est pas présent. J’ai même rencontré plusieurs groupes qui avaient passé du temps (et soufferts) à faire la migration d’AngularJS 1 vers AngularJS 2.

Pour les projets avec des IHM moins ambitieuses, je rencontre aussi beaucoup Bootstrap – créé par Twitter – qui permet rapidement d’obtenir des pages HTML sympathiques.
Je commence également à rencontrer des projets utilisant React créé par Facebook), c’est un framework qui attise beaucoup la curiosité des étudiants.

Pour les développement mobile, je ne rencontre que des développements natifs. En effet, comme c’est trop facile (sic), les étudiants n’ont pas le droit à l’école d’utiliser des plateformes hybrides de type Cordova, PhoneGap ou Ionic même s’ils m’en parlent régulièrement.

Les développements côté Android se font donc naturellement sous Android Studio. En arrivant à l’école je me suis ainsi rendu compte que j’étais le seul (le dernier ?) qui utilisait encore Eclipse.

Pour les développements iOS, il n’y a pas le choix, c’est Xcode qui est utilisé. Par contre la majorité des projets se font maintenant en Swift plutôt qu’en ObjectiveC. J’ai même vu des projets migrer d’ObjectiveC vers Swift et je rencontre régulièrement des étudiants qui migrent – dans la douleur – vers la dernière version de Swift.

Cela peut paraître surprenant mais il y a très souvent des développements sous… Windows Phone (si, si). Bon en fait c’est un peu de la triche car là l’école impose aux étudiants de faire du multi-plateforme, y compris Windows. J’ai rencontré plusieurs projets qui avait fait le choix de faire du Windows Universal pour fonctionner à la fois sur Windows 10 et Windows 10 Mobile, sinon ils font du classique (et périmé) développement Windows Phone.

A noter que je rencontre beaucoup de développeurs « Fullstack », c’est-à-dire capable de travailler sur toutes les couches. Par contre, les développeurs mobiles sont généralement spécialisés: ceux qui font de l’Android ne font pas de l’iOS et réciproquement. Question de religion probablement 🙂

Les autres outils

Pour ce qui est de la gestion de source, même si l’école utilise encore SVN, c’est clairement Git qui fait l’unanimité. Les projets des étudiants sont donc hébergés sur une des plateformes principales : Github qui propose un abonnement « Pro » gratuit pour les étudiants, Gitlab ou Bitbucket. Les étudiants maîtrisent généralement assez bien la gestion des branches dans Git.

L’école sensibilise les étudiants au développement agile et à l’intégration continue. Les projets intègrent donc presque systématiquement des tests unitaires, notamment avec Mocha pour node.js. On trouve également sur certains projets des vraies plateforme d’intégration continue comme Jenkins.

Pour la documentation des APIs, qui est également imposée, les étudiants utilisent des plateformes de génération automatique à partir des commentaires dans le code: principalement APIDoc ou Swagger.

Pour ce qui est de la communication au sein du projet Slack est utilisé par tous. Pour l’organisation des tâches, on retrouve également souvent Trello.

Conclusion

Le titre de ce billet est volontairement provocant: l’ensemble des technologies décrites ici ne sont pas nécessairement celles que l’on retrouvera demain dans toutes les entreprises. Elles sont pour beaucoup très récentes, ne sont pas toujours matures, et certaines disparaîtront peut-être sans jamais arriver à maturité !

Il n’empêche que ces technologies sont portées par de nombreuses startups et qu’elles disposent d’un véritable écosystème. Il est donc important, même dans une entreprise avec un SI qui a quelques années, de s’y intéresser si ce n’est pas déjà le cas. D’autant que les étudiants que je côtoie, qui sont vos futurs collaborateurs, vous en parlerons surement lors de leur entretien de recrutement et que votre réponse sera déterminante pour leur choix 🙂

Article publié le 26 janvier 2017