Bonjour et bienvenue pour cette session de Disruptive live autour de la technologie IPfabric. Je me présente, je m'appelle Tylman Kreft, je suis channel développeur manager pour la région francophone. Donc mon rôle est de développer commercialement parlant notre technologie de network assurance pour la France et toute la région francophone. Le but aujourd'hui et je vais avoir en fait un rôle un peu différent aujourd'hui, c'est de pouvoir être intervieweur pour discuter d'un sujet qui est réellement passionnant et qui occupe une place de plus en plus importante dans les discussions que l'on peut avoir avec des décisionnaires pour l'infrastructure IT comme des ingénieurs réseau qui est le net Devops et qui de mieux pour en discuter que l'une des premières personnes voire la première personne en France qui a évangélisé ce sujet Gilbert Moizio. Gilbert bonjour.

Bonjour, Bonjour. Tout d'abord merci beaucoup d'avoir accepté notre invitation pour cette session et cette interview. C'est un plaisir. Super. Donc Gilbert pour les personnes qui ne te connaissent pas, est-ce que tu pourrais te présenter et expliquer un peu ton rôle et tes activités.

Alors moi je suis consultant senior en infrastructures et méthodologie pour la société NXO qui est un intégrateur français et je contribue au développement de l'activité Net DevOps au niveau national. À ce titre, en fait, je je coach au niveau technique l'équipe Net DevOps de NXO puisqu'on a une équipe dédiée pour pour ce sujet-là. D'accord, très bien. Est-ce que tu as d'autres activités qui qui te passionnent ou qui t'occupent Je fais beaucoup de recherches dans dans différents domaines qui touchent tout ce qui est réseau bien sûr, mais aussi mathématiques, blockchain, le web trois point zéro enfin à tous ces sujets là je suis pas mal impliqué. Parfait donc en préambule avant de vraiment partir dans cette interview je voulais juste mentionner donc que cette interview devrait durer environ vingt minutes et ce fera se déroulera complètement en français.

Mais donc pour ceux qui ne parlent pas français ne vous inquiétez pas nous allons mettre en place et vous devrez voir donc des sous titres en anglais qui vous permettront de suivre cet échange et cette interview voilà donc pour débuter Gilbert est ce que tu pourrais nous expliquer ou nous décrire qu'est ce qu'est le cette approche net des bobs et quelle est sa valeur ajoutée pour des entreprises Alors peut-être peut-être avant de parler de Net DevOps, c'est de refaire un petit peu d'historique d'où d'où est d'où est parti le le sujet. Alors en fait, ça a commencé en deux-mille-treize par la création de scripts d'automatisation. Alors, il est évident que l'automatisation n'est pas un sujet nouveau. Tous les gens qui ont de l'ancienneté dans le domaine du réseau ont utilisé de l'automatisation depuis très longtemps. Mais par contre ce qu'on a vu arriver c'est progressivement des protocoles des standards des formats de données qui ont permis de structurer un peu la démarche ensuite ça a évolué petit à petit et c'est devenu ce qu'on a appelé l'infrastructure as code donc ça consistait en fait à en fait à modéliser l'infrastructure sous une forme de variabilisation et ensuite via toujours pareil des scripts de pouvoir générer un certain nombre de configurations.

Alors comme on avait un ensemble de scripts, il a fallu les rendre plus conviviaux à utiliser et on est passé par l'étape network as a service, donc une interface graphique qui permettait d'accéder au script d'une manière plus conviviale. Et puis enfin, il y a un standard qui est en préparation qui s'appelle l'intent base networking. On aura certainement l'occasion d'en reparler. Et en fait, c'est là qu'on a commencé à avoir l'apparition du modèle DevOps qui en fait un ensemble de pratiques effectivement dans lesquelles on trouve l'automatisation l'automatisation n'est qu'un élément de ces pratiques en fait on amène au réseau la dynamique que l'on connaît dans les applications Ça fait des années qu'on a cette dynamique pour créer des applications, pouvoir les déployer très vite, les tester, les déployer, les simuler. Et en fait, on amène ça dans l'infrastructure et le tout en améliorant la sûreté de fonctionnement parce qu'il est évident que c'est bien gentil de gagner en vitesse mais si c'est pour perdre en sûreté de fonctionnement, on n'y serait pas gagnant.

Donc il y a des méthodologies, des outils qui permettent d'améliorer la sûreté de fonctionnement. D'accord et donc tu mentionnais donc l'intenbase networking alors est-ce que pour toi il faut d'abord passer par l'intenbase networking avant de d'avoir cette approche Net DevOps où les deux en fait sont intercomplémentaires Non en fait, on on va dire que ce, elles sont complémentaires. À dire que l'intend base networking, c'est un standard qui est en cours de ratification à l'i ETF, en fait pour être précis à l'i RTF est en version neuf actuellement, il décrit en fait un certain nombre de démarches et pour mettre en place ces démarches de manière effective, il faut avoir une approche net devops, c'est-à-dire des outils, des méthodes, des des profils de personnes, des compétences, un certain nombre de choses qu'il va falloir réunir si on veut être certain de pouvoir mettre en place l'Inbound base networking de manière de manière efficace. D'accord et est ce qu'il y a un profil type d'entreprise pour lequel ça va s'adresser donc le le net devops que ça soit en taille d'entreprise, en taille de réseau ou alors secteur d'activité. Alors secteur d'activité non, taille d'entreprise oui forcément en dessous d'une certaine taille il n'y aura peut-être pas chez le client les personnes qui auront le profil pour pouvoir intégrer une équipe parce que dans l'approche Net DevOps, il ne faut pas perdre de vue qu'il y a le DevOps.

Le DevOps, c'est un principe de fonctionnement dans lequel on intègre différentes personnes dans une équipe commune. En fait, ce que l'on fait, nous, c'est qu'on intègre le client dans l'équipe. Donc s'il y a personne chez le client qui a des compétences pour pouvoir le faire ça va être difficile de l'aborder sous cet angle là on sera dans une démarche plus traditionnelle où on produit et on livre et non pas dans lequel on partage véritablement un fonctionnement en équipe. Et puis, il faut que le réseau ait peut-être un minimum de taille. Il n'y a pas de chiffres précis, mais c'est vrai qu'un tout petit réseau de quelques équipements, ça n'a peut-être pas trop de sens de de vouloir imaginer de de mettre en place une démarche comme celle-là.

D'accord très bien donc tu nous expliques un peu donc la démarche d'intendbase networking est ce que tu veux un peu décrire comment cela marche Quelles sont les les différentes approches, les différentes étapes Alors d'une manière très synthétique, on a deux boucles. Des boucles parce que de toute façon on est en DevOps et on se rappelle de l'infini qui est le symbole du DevOps là qu'on est dans une amélioration continue donc on a une boucle interne qui est celle qui est utilisée aujourd'hui qui consiste en fait à partir d'une source de vérité avec une bonne gestion des des secrets, de créer un certain nombre de programmes qui vont permettre de configurer des équipements. Une fois qu'ils sont configurés, on va les monitorer et les observer. Donc, il y a, ce sont deux éléments qui sont complémentaires, on pourra le détailler après. Et en fait, tout ça avec des rapports, des comptes rendus automatisés qui vont permettre en fait le maintien opérationnel, mais à la vitesse du logiciel.

Ça c'est une boucle interne donc en fait on revient au point de départ on repart de notre source de vérité on améliore et puis on continue comme ça. Que tu entends par source de vérité pour ceux qui ne connaissent ou qui ne sont pas forcément familiers avec ce terme-là Alors la source de vérité, c'est un terme qui est apparu il y a quelques années suite à la démarche d'infrastructure à scotch. Je parlais de variabilisation tout à l'heure. En fait, c'est la variabilisation, mais poussée à son extrême, c'est-à-dire qu'on va avoir une généralement une base de données c'est pas une obligation mais c'est quand même plus structuré une base de données dans laquelle on a toutes les informations qui décrivent la façon dont l'infrastructure est configurée les paramètres les valeurs les variables tout un tas d'éléments d'information et en fait on l'appelle la source de vérité parce que c'est la référence c'est la référence à partir de laquelle tout va découler toute la configuration les programmes vont découler en fait de cette source de vérité qui de préférence doit être unique d'ailleurs c'est ce que spécifie le standard c'est c'est une source de vérité unique. D'accord très bien et donc tu parlais donc d'une boucle une boucle interne et j'imagine donc il y a une boucle externe qui va aussi avoir d'autres composants qui vont rentrer dans ce dans cette approche.

Alors la boucle externe effectivement elle vient encapsuler la boucle interne. C'est un habillage qui va être en quelque sorte l'interface homme machine par contre ce que spécifie le standard c'est que alors une approche net devops elle est forcément agnostique c'est ça son but c'est de pouvoir ne pas être rattaché à un constructeur et donc par voie de conséquence les personnes qui vont utiliser les outils qui vont être mis en place ne sont pas censés être des spécialistes de chacun des constructeurs qu'il y a dessous puisque l'outil lui-même est agnostique la personne qui parle elle n'est pas spécialiste et donc elle doit parler en langage naturel et alors là on touche le domaine du NLP naturel language processing qui est un des domaines de l'intelligence artificielle et c'est cette partie là qui va certainement être utilisée pour pouvoir réaliser la boucle externe donc une personne en langage naturel va demander quelque chose genre je veux créer des VLAN dessous il y a plusieurs constructeurs on ne sait pas forcément d'ailleurs comment il faut le faire sur chacun de ces constructeurs mais le système va comprendre que la personne déjà veut réaliser ça c'est la première étape et ensuite va s'occuper de savoir comment il faut le faire en fonction des constructeurs qui sont dessus.

Et donc Gilbert pour en revenir à IPfabrique, en quoi IPfabric peut s'inscrire dans ce dans ce contexte de Net DevOps et quelle quelle va être la valeur ajoutée de cet outil pour cette approche Alors, IP fabrique, c'est un produit qui peut être utilisé pour nous en ce qui nous concerne en fait on utilise principalement d'autres capacités du produit pour s'inscrire dans la fameuse boucle interne dont on parlait tout à l'heure C'est la capacité d'observabilité, c'est-à-dire qu'en fait le le le avec on va on va analyser le réseau en niveau deux et en niveau trois grâce aux capacités d'IP Fabrique et à la modélisation qui a été inclus dans le produit IP Fabrique que l'on va interroger nous par API puisque tout est API dans le produit IP Fabrique ça tombe bien nous dans les développements que l'on fait on va interroger le produit pour ne pas réinventer la roue puisque le produit est capable à la fois de donner un certain nombre d'informations sur tout un tas de protocoles mais également de permettre des tests d'acceptation, c'est-à-dire qu'on peut vérifier qu'un protocole est capable de transiter entre deux points du réseau et de dire par quel chemin c'est passé ça ça nous intéresse parce que ça sert à rien qu'on recrée complètement cette partie là ça répond à un pavé complet de l'Inten base networking qui s'appelle Observability dans le standard et donc en fait on a la réponse avec ce produit là donc c'est en ce titre là que nous nous le produit nous intéresse parce qu'on fait on fait tous les tests d'acceptation avec.

D'accord. Est-ce que tu vois aussi un potentiel par rapport à générer ou on doit populler des informations dans la source de vérité dans certains cas avec des informations générées par Ipe Fabrique. Alors nous on a on a pour habitude parler donc de la source de vérité dont on a parlé tout à l'heure qui est en amont en fait on a décrit à l'intérieur l'infrastructure et on parle de source de réalité en fait quand on quand on a IP fabrique c'est-à-dire que IP fabrique lui va relever la réalité de ce qui est sur l'infrastructure pour ça qu'on va l'appeler la source de réalité et notre objectif ça va être au minimum de vérifier que la source de vérité est bien conforme à la source de réalité pour que notre notre source de vérité garde sa cohérence et ne dérive pas avec le temps si des gens oublient de la de la corriger. Donc on va faire au moins ce contrôle. Après, pourquoi pas peupler la source de vérité avec la source de réalité, mais alors ça voudrait dire qu'on n'a pas pris le projet à son début.

On arrive sur un réseau qui est déjà existant et sur lequel le client voudrait mettre en place la démarche net de vote. Alors ça peut arriver, mais ce n'est pas le cas le plus fréquent parce qu'en général les clients profitent du changement d'une infrastructure aujourd'hui pour le faire avec cette nouvelle approche qui devient incontournable plutôt que de chercher à l'appliquer à quelque chose qui existe déjà et qui tourne ça fait toujours un petit peu peur aux clients de dire toucher quelque chose qui fonctionne c'est prendre le risque de le perturber, de perturber des habitudes qui ont été mises en place. Donc ça nous arrive beaucoup moins de peupler des sources de vérité avec la source de réalité. Mais par contre les comparer oui très souvent. D'accord et tu penses que avoir cette boucle interne donc une boucle d'acceptation est quelque chose de vraiment critique dans cette approche où on peut réaliser donc un modèle Net DevOps sans ce pan là de validation.

Alors c'est c'est c'est très critique parce qu'on va, on est dans le monde applicatif, on va travailler en mode agile avec des méthodes, alors CAN CANBAN, alors nous, ça sera plutôt, on prend le meilleur des demandes, SCRUM et CANBAN. Et dans ce domaine, dans cette approche, on a beaucoup de tests, alors des tests d'acceptation, mais aussi des tests unitaires. On va avoir également des défis, ce qu'on appelle les définitions of dodds, c'est-à-dire qu'est-ce qui permet de dire qu'une tâche est terminée, pas juste parce que je l'ai fini, mais probablement parce que j'ai fait des tests pour vérifier que ça fonctionnait. Donc de toute façon, les tests d'acceptation qui sont la vision utilisateur, utilisateur ça peut être administrateur réseau, mais en tout cas une autre vision que les que les techniciens eux-mêmes, ça ça ne se fait qu'avec des des tests qui traversent l'infrastructure. Or, qui traversent l'infrastructure.

Or, soit on est sur un simulateur et c'est relativement facile puisqu'on utilise des simulateurs en amont, soit si on est sur l'infrastructure réelle, il va falloir aller mettre des petites machines à droite à gauche pour servir de sonde, de générateur de trafic et pour vérifier que ça traverse comme on veut l'infrastructure. Ce n'est pas forcément très pratique. Alors pour le faire sur l'infrastructure réelle, IP fabrique va faire des snapshots, donc on va aller ponctionner les configurations des équipements et tout un tas d'informations qu'on va trouver dans les tables, tables ARP, table de routage et autres et grâce à toutes ces informations le produit va modéliser en fait le comportement de l'infrastructure et donc là, on est libre d'aller mettre des pseudos équipements virtuels qui n'existent pas et de dire je génère un trafic d'un côté et je le regarde si je le reçois de l'autre mais sans aller mettre un PC sur le réseau physique en fait on le fait on le fait sur la partie simulation du de l'IP Fabrique donc à un moment donné on peut s'en passer bien sûr on peut aller mettre sur le réseau sur l'infrastructure des PC un peu partout soyons fous on va acheter tout un tas de Raspberry Pi et puis on va les éparpiller partout oui ça fait ça fait l'affaire mais bon à la fin c'est un peu compliqué d'avoir des dizaines de Raspberry Pi éparpillés partout et de générer des tests dans tous les sens c'est quand même plus facile de le faire sur un simulateur alors ce qu'on appelle IP Fabrique on l'appelle parfois nous le simulateur post production parce qu'on a les simulateurs pré production qui vont être plutôt des simulateurs de type FNG et puis après ça c'est plutôt un simulateur post-production c'est-à-dire qu'il va aller aspirer la réalité et la simuler.

Très bien et comme tu mentionnais l'importance aussi c'est d'avoir cette approche agnostique dans la manière dont on représente la réalité et comme tu disais Ip fabrique ne va pas se cantonner sur un seul constructeur mais va vraiment concentrer sur la technologie en soi. Et j'imagine que ça aussi c'est un des points qui t'a fait, pourquoi ce qui t'est fait dire que ça pourrait être un un outil intéressant dans ce modèle-là j'imagine. De toute façon, étant donné que le résultat final d'une aide develop, c'est d'être agnostique, il faut que tous les composants qu'on utilise le soient. Alors ça n'empêche pas que dessous après quand on arrive sur les matériels constructeurs, là c'est dédié, on peut même avoir une couche de management qui vient du constructeur et on peut très bien, comme on nous le demande parfois, aller configurer les équipements en passant par la couche de management et non pas en adressant directement les équipements. Mais nous, il nous faut quand même cette approche agnostique.

Donc, le fait qu'IP fabrique supporte plusieurs constructeurs et on va dire les principaux constructeurs du monde de l'automatisation potentiellement on peut tout automatiser nous on est on est transverse ça va être ça va être les réseaux, les serveurs, la sécurité et sans sans limite de constructeurs du moment qu'il y a une interface pour accéder au constructeur, même SSH à la limite. Mais ceci étant, aujourd'hui, il y a quand même sur ces grands réseaux dont on parlait tout à l'heure, il y a quand même un certain nombre de constructeurs qu'on va retrouver un peu systématiquement. Et ce sont ceux qui sont dans IP Fabrique donc ça tombe bien. On évoquait plutôt donc les changements de paradigme on va dire des évolutions dans les pratiques, c'est quelque chose que tu m'avais mentionné lors de nos discussions précédentes que déjà dès deux mille treize tu évangélisais l'approche net des bops tu Est-ce qu'on observe actuellement donc en Europe et plus précisément en France puisque tu es actif et en France un réel changement donc dans ces pratiques net devops. Oui, le changement, on l'a vu.

Alors la vague, moi, je l'avais, je l'annonçais depuis déjà pas mal d'années, mais elle est arrivée véritablement aux alentours de deux-mille-dix-neuf sur la France et là maintenant rares sont les clients dont la taille correspond à la cible dont on parlait tout à l'heure qui ne veulent pas au minimum se poser la question de savoir comment s'il faut y aller, comment y aller. Or la question aujourd'hui, je ne pense pas que ça soit est-ce qu'il faut y aller. Il ne faut pas reproduire la même, le même schéma que dans les années deux mille avec la théorie p. La question, c'est, c'est, c'est comment y aller c'est c'est pas faut-il y aller c'est pas quand est-ce qu'il faut y aller est-ce qu'il faut y aller la réponse est oui quand au plus tôt maintenant la question c'est comment comment y aller et je pense que beaucoup beaucoup de clients vont gagner du temps s'ils se posent la question sous cet angle-là Vraiment qu'est ce qui a changé on va dire dans les mentalités pour que de plus en plus d'entreprises prennent du temps à considérer ces sujets de réflexion est-ce que c'est aussi un mouvement de mode et de voir que d'autres compétiteurs ou d'autres grandes entreprises passent plus de temps et de ressources dans ce sujet-là Il est possible qu'il y ait un aspect de compétitivité, ça c'est possible, le time to market est un sujet qui préoccupe les entreprises, mais je pense que le souci c'est qu'en fait les applications ont commencé très tôt à pouvoir adopter toutes ces pratiques de manière en fait à pouvoir imaginer à longueur de journée pousser des modifications sur les applications sans perturber leur utilisation les serveurs les toutes les parts toute la partie machine virtuelle containers se sont adaptés aussi pour être très rapides, très réactifs et suivre la cadence des applications, mais l'infrastructure dessous et a fortiori l'infrastructure réseau était quand même un goulot d'étranglement qui n'était plus acceptable donc il a été réfléchi comment faire pour imaginer que cette infrastructure ne soit plus un point de blocage un boulot d'étranglement et en fait c'était une évidence que ce qu'il fallait c'était appliquer les recettes qui avaient fonctionné sur les applications et sur les serveurs il fallait l'appliquer à l'infrastructure dessous et donc on s'est retrouvé comme ça avec l'approche net DevOps.

Tu disais donc maintenant la question n'est plus si oui ou non il faut passer à une approche mais comment j'imagine là on parlait d'une approche qui doit être quand même assez lourde ou alors assez complexe donc il nécessite aussi beaucoup de personnes qualifiées j'imagine qu'un prestataire ou des prestataires doivent être mandatés pour réaliser ces projets là Selon toi quelles sont les bonnes qualités ou comment tu qualifierais un bon prestataire qui pourrait mener à bien ce genre de sujet et de projet. Alors on est sur un sujet qui est très vaste, qui comporte beaucoup de points de compétences. Alors de toute façon déjà, il faut une équipe dédiée et entraînée. On peut pas faire ça de manière anecdotique c'est quelque chose qu'il faut pratiquer tous les jours Il faut déployer également des moyens adaptés parce qu'on va se rendre compte que dans beaucoup d'acteurs du marché aujourd'hui les les moyens qui sont en place que ce soit des moyens logistiques des moyens informatiques ne sont pas adaptés en fait à ces approches-là. Il n'y a pas assez d'agilité dans ces infrastructures.

Il faut souvent des moyens adaptés, il faut consacrer beaucoup de temps à la formation, ça c'est facile à déduire du fait qu'il y a énormément de compétences à à acquérir et comme on parle quand même avant tout de l'infrastructure réseau dans le Net DevOps, Net, c'est pour le réseau network, C'est bien que dans l'entreprise, au moins dans l'entreprise, même si ce n'est pas dans l'équipe, il y ait de fortes compétences réseau pour pouvoir quand même réaliser des architectures, les designer, être capable de réaliser les configurations. Donc ce qu'on va appeler dans le jargon technique, faire le HLD, le HLable design et le LLD, le level design. Donc ces documents-là, il va falloir être capable effectivement de les réaliser. On ne sait pas forcément fait dans l'équipe parce que l'équipe possède des compétences réseau, mais pas de très haut niveau, en tout cas comparé à des gens qui eux font du travel shooting, de la conception du travel shooting de réseau exclusivement. Donc voilà voilà à peu près les qualités qu'il va falloir déployer pour pouvoir répondre à ce besoin.

D'accord super. Après nous on connaît bien les compétences de NXO sur différents sujets puisqu'on travaille ensemble sur différents comptes et c'est la raison d'ailleurs pour laquelle on t'a invité aujourd'hui une question qui je pense intéresse tout le monde c'est à quel point c'est facile de réaliser ce type de projet et est ce que tu as des exemples concrets de réalisation qui a été fait par Enixo sur l'approche Net DevOps Alors en fait facile, salé, salé parce que ce que l'on fait, c'est que l'on on on coproduit le résultat avec l'équipe du client. Donc on va mettre des personnes de chez nous, de l'équipe Net DevOps, on va mettre des personnes du client et on va passer par des phases notamment par des phases de training donc le but c'est véritablement que l'équipe c'est une véritable équipe qu'on est en train de monter chez chez le client ou avec le client. Une équipe dédiée ou qui va avoir d'autres d'autres formations, d'autres tâches pardon. C'est une équipe dédiée on est en agile le principe agile c'est que ça va être une équipe qui va être dédiée pendant la durée de la réalisation du produit final et et cette équipe là en fait va commencer par une phase d'entraînement ce qui est logique pour une équipe même dans le sport donc en fait elle va s'entraîner pour niveler les pratiques, éventuellement les connaissances, les façons de collaborer ensemble.

Donc ça, c'est, c'est, c'est, c'est avant tout important pour que à la fin, le produit soit le produit du client. Nous, on ne vend pas un produit pour lequel on veut derrière aller vendre de la maintenance. Ce n'est pas ça. On réalise, on coréalise ensemble un produit qui deviendra la propriété du client et dont il va s'accaparer la connaissance et les compétences pour pouvoir le faire vivre après quand nous on se retire et donc des exemples on en a eu beaucoup depuis nous, on a commencé en fait à le réaliser en France en deux-mille-seize pour les premières réalisations. Alors évidemment, je n'ai pas les autorisations des clients pour les citer, mais on a dans des domaines de collectivité, d'aéronautique, d'énergie.

Alors, il y a un exemple lui peut être cité parce qu'il est visible dans YouTube. Il y a eu un reportage qui a été fait dessus, c'est c'est l'aéroport de Nice Côte d'Azur. Donc on peut trouver dans YouTube l'interview du du client dans le dans donc sur lequel on a déployé un environnement Net DevOps à base de de Juniper avec un simulateur avec du Gitlab, du docker, du du docker Swarm, il y a cluster docker avec du cluster FS pour le stockage, du Python, du robot framework pour les tests, il y a du Grafana, du Prometheus, du GN MIC pour faire des tests sur toute la partie genimage RPC, donc la télémétrie en fait la télémétrie qui est un autre terme un petit peu différent du monitoring, même si on les met un peu ensemble, mais le monitoring, c'est là, c'est le serveur qui va chercher les informations sur les équipements et en télémétrie, ce sont les équipements qui renvoient les informations vers le serveur. Donc voilà, il y a eu un certain nombre d'éléments qui ont été déployés. Du client.

Voilà le client, même si au début la démarche pouvait sembler compliquée, en réalité il s'en est très bien sorti et et aujourd'hui il continue j'ai des nouvelles il continue à faire évoluer ce qui avait été mis en place il l'a il l'a amélioré il est toujours dans cette démarche-là et d'ailleurs il est dans, en ce moment en train de regarder la partie observabilité qui, qui n'avait pas été mis en place lors de, lors de ce projet et là il s'interroge sur effectivement la possibilité de peut-être intégrer maintenant ça dans sa dans son dans toute sa boîte à outils. Parfait donc voilà j'invite tout le monde à consulter cette vidéo et voir un peu le retour donc du client l'aéroport Nice côte d'azur voilà. Gilbert peut-être quelques mots de fin alors est-ce que tu as pour conclure pour pour les gens qui nous regardent cette approche là en quelques mots est-ce que c'est une approche d'avenir et quel est le futur peut-être du Net DevOps ou est-ce qu'il y aura un autre domaine peut-être qui va émerger Alors les les compagnies qui font les analyses de marché avaient prédit qu'en deux-mille-vingt-deux, il y aurait une un passage du monde du script au monde de l'application bon ils se sont pas trompés parce qu'en fait nous on nous demande de plus en plus de réaliser des maintenant au lieu d'avoir des ensembles de scripts, ce sont de véritables applications avec une interface graphique qui sont qui est une application qui est personnalisée pour le besoin du client.

Donc ça c'est c'est c'est la ça c'est aujourd'hui c'est pas le futur alors le futur c'est peut-être passer vers un langage de compilation. Alors on pense que Golang va être certainement de plus en plus utilisé. Aujourd'hui, on est en Python, on a en python JavaScript pour les frontanes on peut peut-être imaginer que demain quand on aura besoin de faire de la télémétrie et d'avoir des vitesses de traitement très élevées, on va être en Golang. D'ailleurs, le Golang est utilisé pour beaucoup, pour réaliser beaucoup d'outils que nous, on va utiliser dans le monde du Net Evox, que ça soit, que ça soit pour la gestion des secrets, que ça soit pour le provisionning dans le cloud avec Terraform. Donc, tous ces outils-là sont écrits en Boulant.

Oui, il y a des chances que peut-être on fasse tout ou partie des prochains développements avec du langage compilé mais c'est pas c'est certainement pas le plus gros changement qu'on va avoir le plus gros changement c'est que l'intelligence artificielle, on va le retrouver un peu partout. Et d'ailleurs, c'est pour ça que nous, dans l'équipe, on a, on a des personnes qui sont spécialisées en mathématiques et en intelligence artificielle parce qu'on pense que c'est effectivement ça qui va être l'élément le plus déterminant et sur lequel les compétences ne sont pas forcément les plus standards. Faire des programmes Python, ce n'est pas peut-être pas donné à tout le monde, mais on peut faire des petits programmes après des bons programmes. Plus on veut une application et plus il faut être développeur, mais par contre faire de l'intelligence artificielle, là par contre ce n'est pas à la portée de quelqu'un qui ne serait pas spécialisé sur le sujet. Donc voilà les éléments qu'on pourrait placer dans le futur.

Il ne s'agit pas non plus d'un futur à dix ans, c'est un futur à deux ans probablement. Mais sinon, ce que je pourrais dire, c'est ne pas hésiter à en parler, ne pas hésiter à à demander d'avoir une discussion ne serait-ce que pendant une heure pour échanger sur ces sujets-là avec peut-être des détails supplémentaires qu'on n'a pas eu le temps d'aborder là et qui peuvent permettre de d'y voir plus clair et de rassurer parce que souvent on a peur de ce que l'on ne connaît pas et si en fait on découvre un petit peu ce qui se cache derrière le monnaie DevOps quels sont les avantages et pourquoi c'est incontournable Certainement que ça sera moins effrayant. Bien sûr et c'est pour ça qu'on a vraiment cette approche consultant auprès des entreprises qui veulent se lancer et comprendre vraiment ce qu'ils veulent atteindre. Parfait Gilbert merci beaucoup pour le temps que tu nous a consacré et toutes les réponses que tu nous as fourni c'était vraiment intéressant. Merci à toi et puis écoute on aura l'occasion d'en rediscuter.

Bien sûr. Donc je remercie tout le monde pour avoir vu cette vidéo, je vous invite aussi à regarder les autres sessions qui vont se dérouler donc au sein de disruptive life et donc voilà c'était Timman Craft et je vous remercie à bientôt au revoir. Au revoir.