Mais que deviennent t-ils ? Florian Lacommare nous raconte son expérience avec le SDN.

Dans le cadre de l'animation de la communauté des alumni, l’association des alumni de l’Epita a décidé de mener l’enquête sur l’évolution des anciens élèves après l’obtention de leur diplôme. Cette semaine et dans le cadre du mois consacré à la spécialité TCOM nous revenons sur le parcours de Florian Lacommare un TCOM diplômé en 2013.

Florian, pouvez-vous revenir sur votre parcours et nous raconter un peu comment avez-vous choisi l’école Epita, puis la spécialité TCOM ?

Florian Lacommare : A la fin du lycée il faut trouver ce qu’on veut faire dans notre vie, pour moi il a été assez intuitif de choisir l’informatique car je ne voulais plus avoir un cursus classique. Mon choix s’est donc porté sur EPITA plutôt qu’une école d’ingénieur généraliste. Une fois dans l’école j’ai choisi la majeure TCOM car c’est celle qui touchait le plus à un sujet qui m'intéressait et que je trouvais un peu mystérieux : le réseau.

Suite à votre parcours à l’Epita, vous avez fait votre stage de fin d’étude au sein de l’entreprise Metanext une ESN spécialisée dans le Cloud. Pouvez-vous nous raconter vos premiers pas dans cette entreprise ?

FL: J’ai rencontré Metanext lors d’un forum entreprise organisé au sein d’EPITA. J’ai été le deuxième stagiaire à être embauché chez eux, nous étions moins d’une centaine à l’époque. Je voulais m’orienter vers la technologie Datacenter et mon sujet de stage a donc été de comprendre comment fonctionne un datacenter et les outils utilisés, aussi bien en réseau qu’en système ou en stockage. A l'époque, j'ai également dû me former sur les technologies utilisées dans cet écosystème, notamment la gamme de produits Cisco Nexus qui était assez nouvelle à l’époque.

A la fin de mon stage j’ai été embauché en CDI et j’ai débuté une mission de 1 an et demi dans les équipes de sécurité chez Carrefour. La sécurité n’était pas le domaine dans lequel j’étais le plus à l’aise mais ils cherchaient des profils à faire monter en compétence donc j’ai accepté. Après une seconde mission chez ENGIE, Carrefour m’a rappelé pour un poste dans l’équipe d’architecture des Datacenters car je leur avais communiqué mon intérêt pour le sujet. L’avantage c’est que Metanext est une boite très à l’écoute de ses salariés et ils ont facilement accepté que je change de mission.

J’ai alors démarré une longue période dans cette équipe avec un beau projet de refonte.

Et puis le monde évoluant et les technologies avec, je me suis intéressé à l’automatisation et aux Software Define Networks (SDN).

En 2018, nous (Metanext et moi) avons eu l’idée d’avoir une équipe dédiée à ces sujets. C’était assez précurseur à cette époque, surtout pour une ESN de cette taille, mais on a fait le pari et malgré les difficultés de manque de ressources humaines et de compétences disponibles sur le marché ça a pris. Et comme l’idée a intéressé Carrefour on a également monté une équipe de ce type chez eux.

J’y suis toujours aujourd’hui et ça se passe très bien.

Software Define Network et automatisation réseaux, ce sont les sujets auxquels votre équipe est dédiée. Est-ce que vous pouvez nous expliquer ces concepts ?

FL: En 2013, quand je me suis intéressé aux SDN c’était un mot académique qui désignait le fait de faire piloter le réseau par un logiciel. L’objectif étant de faire des économies en optimisant, par exemple, le coût des accès à internet qui diverge selon les opérateurs en configurant le réseau en fonction du prix du lien ou de la criticité du trafic. Cela pouvait également servir à anticiper des changements de configurations en cas de panne.

Aujourd’hui ce concept s’est un peu perdu et le terme est à mon sens beaucoup plus marketing quand il est utilisé par les revendeurs d’équipement réseau. Ma définition serait une solution qui a été packagée par un constructeur et qui vient piloter le réseau. Les plus connus étant CISCO ACI et VMware NSX. Leur principe est d’avoir un contrôleur qui donne des ordres à des boîtiers virtuels ou physiques qui restent intelligents et donc autonomes alors que dans la définition initiale du SDN le boîtier ne l’est pas et dépend à 100% du contrôleur.

Ce qui fait la force de ces solutions, c'est que leur contrôleur expose des API qui va permettre d'inclure le réseau (sa configuration, son déploiement, etc) dans notamment des outils de portail self service pour faire du Cloud privé ou hybride et commander des services à la demande comme on le retrouve chez les fournisseurs de solutions Cloud (AWS, Azure, Google Cloud Platform).

Sur la partie définition de l'automatisation réseau, j’ai également ma propre définition : pour moi c’est quant au lieu d’acheter un contrôleur chez un éditeur, c’est nous même qui allons développer les cas d’usages dont on a besoin pour que le réseau se configure seul. Cette solution permet de réduire les coûts induits par l’achat d’un logiciel très générique et avec beaucoup de cas d’usage dont nous n’avons pas forcément besoin.  On remplace en revanche les coûts logiciel par des coûts humains. On utilise pour cela des équipements réseaux qui sont capables d’être automatisés car ils ont, entre autres, des API. On retrouve dans ce domaine pratiquement que des technologies open sources. 

Vous nous parlez depuis tout à l’heure d’automatisation du réseau, d’autonomie des boîtiers, est-ce que je dois en déduire que l’intelligence artificielle à sa place dans le domaine ?

FL: On en retrouve de plus en plus comme dans la plupart des domaines mais je ne pense pas que le domaine soit assez mature pour que cela marche.

Je l’ai souvent vu sur des outils qui font de la collecte de logs et qui tente de faire de la prédiction de risques sur les équipements.

L’automatisation de déploiement de serveurs existe également depuis longtemps notamment à travers le logiciel Ansible mais ce n’est que récemment qu’ils ont intégré la partie réseau. Donc on voit bien que le réseau est souvent un peu à la traîne par rapport aux solutions systèmes. Et c’est plutôt normal car finalement tout repose sur le réseau, s’il ne marche pas, rien ne marche et du coup on se doit d’être très fiable et d’avoir recours au principe de précaution. Dans ce contexte, les nouvelles technologies mettent un peu de temps à être mises en place car elles sont jugées risquées.

Quand on parle de DataCenter aujourd’hui, beaucoup d'entreprises parlent de délocalisation dans le Cloud. Comment l’automatisation est-elle entrée en jeu dans ce travail de migration ?

FL: Quand on est dans une grosse boite on a tendance à vouloir faire de l’Infrastructure as Code pour pouvoir exploiter les avantages du cloud (à savoir la ressource à la demande et la rapidité d’obtention de ces dernières). Il y a donc quelques contraintes supplémentaires dans le cloud et des manières de faire différentes, et les consultants en automatisation sont souvent plus à l'aise avec celles-ci car c'est la même philosophie. 

Il faut aussi prendre en compte le fait qu’une entreprise est rarement 100% dans le cloud. On est souvent sur des modèles hybrides et l’automatisation va aider à faire en sorte que les équipes métiers puissent utiliser les ressources des deux systèmes de la même manière afin de leur faciliter la tâche et d’améliorer les démarches internes de demande de ressources.

L'automatisation aide à mettre en place des standards et de la sécurité dans le cloud. Par exemple, une équipe métier qui a besoin d’un nouvel applicatif va pouvoir “commander” un nouveau compte via un portail qui leur est mis à disposition et ce compte va être créé automatiquement tout en étant soumis à une politique globale de gestion des accès et de sécurité. Cela passe parfois aussi par des contraintes et de l'automatisation réseau.

Une entreprise n’a pas besoin d’avoir automatisé son réseau pour migrer dans le Cloud. Au final, même si l'automatisation du réseau "on-premise" n'est pas obligatoire, il y a des avantages indéniables à le faire, mais si on parle de réseau dans le cloud, alors là oui, cela devient obligatoire de l'automatiser. Et cerise sur le gâteau, généralement, les consultants en automatisation réseau sont assez vite à l'aise pour manipuler les services cloud.

Vous dites qu’un des objectifs de l’automatisation est de rendre les équipes métiers plus autonomes. Y a-t-il une politique d’acculturation aux concepts de base du réseau mise en place pour les aider dans la formulation de leurs besoins ? 

FL: Non, le réseau a toujours été un peu à part et est un domaine assez complexe. Pour moi un bon ingénieur réseau doit être capable de traduire les besoins métiers en besoins techniques et réseau.

Mais il est vrai que pour le cloud, bien qu’un cadre soit posé pour des problématiques liées à la sécurité, on essaye de sensibiliser les équipes métiers et les équipes systèmes aux bonnes manières afin de les responsabiliser car l'objectif n'est pas de verrouiller le réseau et la securité, mais bien de les rendre autonome.

Est-ce que je dois en déduire qu’un ingénieur réseau traite également des problématiques de sécurité ou collabore avec les équipes de sécurité ?

FL: De manière générale, les ingénieurs réseaux comprennent tout le langage de l'infrastructure et communiquent donc facilement avec les autres équipes dont les outils reposent sur leur infrastructure pour fonctionner. La sécurité est très liée au réseau, historiquement c’était une seule et même équipe qui traitait les deux sujets.    

Si on retourne un peu en arrière, en quoi la formation dispensée par la spécialité TCOM vous a aidé au long de votre carrière ?

De manière générale, la philosophie de l’EPITA est d’apprendre à ses étudiants à être autonomes. Et c’est une force, car étant recruteur de talents au sein de mon entreprise je constate que dans d’autres écoles on formate les étudiants et cela les rend moins à l’aise lorsqu’il s’agit de sortir des sentiers battus.

En TCOM on nous apprend vraiment les bases de fonctionnement du réseau et il est donc plus simple de comprendre toutes les technologies qui en découlent aussi nouvelles soient-elles.

Il y a aussi les cours de M. STEPHAN qui nous apprennent la vie en entreprise avec des notions comme le benchmark et qui aiguisent l’esprit critique. Ce qui est un sacré coup d’avance quand on arrive sur le marché du travail.

Vous travaillez pour Metanext depuis votre sortie de l’école, ce qui est rare dans le domaine du numérique qui connaît un haut taux de turn-over. Comment expliquez-vous que votre entreprise réponde à toutes vos attentes en termes d’évolution professionnelle ?

FL: Je prendrais la question en sens inverse et je dirais “pourquoi je voudrais changer de boite ?”. Chez Metanext le management est super ce que je trouve très important et il n’y a pas 25000 strates hiérarchiques. Les discussions sont ouvertes et je n’ai pas de mal à dire quand il y a un souci. Les responsables ne sont pas des commerciaux dont le salaire est indexé sur mon taux de staffing, nous investissons dans des profils et on ne veut pas qu’ils partent parce qu’ils sont placés sur des missions qui ne leurs conviennent pas.

Nous ne sommes pas non plus à plaindre d’un point de vue salarial. Encore une fois, la vie du collaborateur et le marché sont pris en compte, on ne fonctionne pas avec des grilles.

J’aime aussi le fait d’être entouré d’experts en infrastructure qui s’entraident et qui créent une communauté à échelle humaine avec une bonne ambiance.

Enfin, on voit bien avec mon exemple que la société fait confiance à ses collaborateurs pour monter ensemble des projets tel que la mise en place de mon équipe.

Nous arrivons à la fin de notre échange, avez-vous un dernier message à faire passer ?

FL: Nous avons besoin de plus d’ingénieurs qui soient formés à l’infrastructure et au Cloud et il n’y a aucune école française qui le fait. Nous sommes souvent obligés d’aller chercher nos candidats à l’étranger et c’est un drame. J’encourage l’EPITA à suivre le marché en ce sens.

Merci beaucoup Florian pour cet échange très intéressant.