Durant mes études supérieures en école d’ingénieur, et dans mes premiers postes dans l’administration, on m’a toujours mis en avant les vertus de l’abstraction et de la compréhension des concepts pour être un “bon manager”. L’idée, c’est qu’au bout d’un moment, plus besoin de savoir faire soi-même dans le détail pour être capable de diriger, piloter. Diriger, piloter, devient une compétence à part entière, indépendante ou presque du sujet sur lequel on l’exerce.
Sans fondamentalement adhérer à ce point de vue, au fond, on se laisse entraîner, et progressivement, on s’éloigne de la compréhension intime des choses. Le premier qui a commencé à me mettre le doute, c’est Jacques Marzin. Quand j’étais à la DISIC (la direction interministérielle des systèmes d’information de l’Etat), il nous disait qu’il faudrait qu’on sache tous coder, qu’on ait tous un projet à côté, il nous parlait des difficultés qu’il avait à monter son cluster hadoop à la maison, … Je ne le prenais pas trop au sérieux, mais ça m’intriguait qu’un directeur expérimenté, qui avait un rôle très large avec un fort leadership sur toute l’informatique de l’Etat éprouve aussi le besoin de se confronter à la réalité.
Maintenant que je suis chez AWS, je réalise combien il avait raison. Dans l’informatique récente, il y a eu un nombre impressionnant de changements de paradigmes, qui finissent par perdre du sens à force d’être conceptualisés. Au bout d’un moment, le concept N+1 qui améliore le concept N qui avait supplanté le concept N-1, ça n’a plus beaucoup de sens, et on devient terriblement superficiel, à sauter d’un concept à un autre, à ne plus réellement distinguer le changement clé du buzz-word à la mode, et finalement ne plus vraiment comprendre précisément, intimement, le problème que chacune des évolutions résout.
Et je reconnais volontiers que malgré la curiosité que j’ai toujours entretenu pour la technologie, j’ai largement manqué certains virages. Et ça pose problème, parce que l’évolution technologique actuelle a introduit, et continue à introduire des transformations profondes, des ruptures, pas uniquement dans le “comment”, mais aussi dans les modèles économiques, les modèles d’organisation, les modèles d’achat, les modèles de sous-traitance.
J’ai donc (re)mis les mains dans le cambouis, et c’est un excellent moyen de comprendre vraiment comment le cloud marche et ce que la technologie change, en profondeur, dans le fonctionnement de l’informatique aujourd’hui. Et cette méthode est assez efficace pour comprendre plus “intimement” les qualités de sécurité, d’élasticité, de coût, … dans le cloud. Et de comprendre à la fois qu’il n’y a pas de magie (et oui ! le cloud, ça reste de l’informatique, il y a de la programmation, il y a des choses très techniques à faire), mais que c’est sensiblement plus simple que de configurer et gérer tout un tas d’infrastructures.
Combien de technologues parlent d’intelligence artificielle, sans avoir la moindre idée de comment ça fonctionne ? Et bien je pense que s’ils testaient Sagemaker, la plateforme d’IA d’AWS, comme je l’ai fait, on aurait beaucoup moins de fantasmes sur ce que c’est ou ce n’est pas, et sur le fait que si ça atteint des résultats extraordinaires aujourd’hui dans certains domaines, c’est le résultat d’un travail remarquable, qui fait appel à beaucoup d’intelligence humaine, et c’est très très loin d’être magique ; et réciproquement, ça reste quelque chose qui s’apprend, qui n’est pas fondamentalement inaccessible pour peu qu’on y investisse du temps.
Dans le même genre, n’hésitez pas à tester les services IoT, les services managés pour les containers, monter des architectures serverless… Dans ma to-do list, il y a encore une chose que je ne comprends que trop superficiellement : ce sont les blockchains ; ça tombe bien, j’ai de quoi faire aussi !
Fondamentalement, je vous encourage plutôt à essayer, à vous créer un compte plutôt que de continuer à lire ce post de blog… Tiens, en parlant de ce blog : une idée sur la façon dont il est fait ? J’ai commencé par me dire : allons sur un blog qui a déjà pignon sur rue (genre Medium). Je trouvais ça dommage de ne pas en profiter pour tester des choses par moi-même. Je me suis donc dit : installons ce blog sur AWS ; je me suis intéressé à l’architecture de référence pour héberger un site wordpress. C’était bien, efficace, avec un inconvénient tout de même : c’est surdimensionné pour un blog perso dont l’ambition reste modeste (avoir des frontaux redondés avec du partage de fichier, une base de données répliquée, du cache intermédiaire, c’était un peu exagéré). J’ai changé d’avis pour me diriger vers une architecture serverless pour la partie distribution du contenu. Comment ça marche ? Très simple : mes pages sont statiques, stockées sur S3, délivrées via cloudfront et route53 pour la gestion du nom de domaine. Les avantages sont nombreux : pas de serveur à gérer, à mettre à jour ; très très peu cher ; très scalable (on sait jamais !). Pour générer les pages, je m’appuie sur hexo, que j’ai installé sur un tout petit serveur EC2 que je n’allume qu’à chaque mise à jour de mon blog pour générer les nouvelles pages ; du coup, pareil, ce n’est pas cher, car ça ne fonctionne que très ponctuellement, c’est simple à sécuriser (au moment où je l’allume, je restreint l’accès à mon EC2 en SSH que depuis mon adresse IP, et je l’éteins ensuite…). J’ai choisi de ne faire que des pages statiques, mais on peut facilement les rendre dynamiques en ajoutant des appels d’API via du code javascript, comme sur cet exemple.
Rien de tel que d’essayer pour se rendre compte !