Dans ce 4ème épisode de notre websérie dédiée au développement numérique durable, nous plongeons plus profondément dans les enseignements précieux de Jean-Philippe Papillon, explorant les thèmes des test et de livraisons.
Retrouvez l'intégralité de cet article sur : https://spote.developpement-durable.gouv.fr/mtect-mte-mer/sg/sg-dnum/sg-dnum-msp/article/le-developpement-numerique-durable-episode-3
Retrouvez l'intégralité de cet article sur : https://spote.developpement-durable.gouv.fr/mtect-mte-mer/sg/sg-dnum/sg-dnum-msp/article/le-developpement-numerique-durable-episode-3
Category
🤖
TechnologieTranscription
00:00 Le deuxième aspect de ce genre de méthode pour éviter de devoir mettre une demi-douzaine,
00:10 voire plus, à développer, c'est qu'on en revient au basique qui fait dire, plutôt que de juxtaposer
00:18 une série d'expertises et avoir à gérer tous les coups de la coordination, parce que c'est ça en
00:26 fait qui est masqué derrière le problème de l'équipe, c'est que du coup il faut que tout
00:30 le monde se trouve. Alors si on a effectivement, par exemple, l'équipe de France, des gens qui
00:34 se sont entraînés, archi-entraînés, qui sont des professionnels, qui se connaissent, qui se trouvent,
00:37 on voit bien, ils jouent mieux en fin de tournoi qu'en début de tournoi parce qu'ils sont entrouillés
00:41 à se connaître, à s'anticiper. Tous ces coups de coordination au sein d'une équipe, eh bien
00:46 il faut les assumer et c'est ça qui ralentit énormément tout le monde. Et d'ailleurs plus
00:52 l'équipe est grande, moins ça avance. Et donc c'est aussi un appel à privilégier les, comment
01:00 ça s'appelle, les profils plus polyvalents, quitte à être moins pointu sur ce sujet,
01:05 les avoir en support, et des architectures aussi surtout plus légères. Alors quand on entend
01:11 l'ET, à chaque fois je l'entends quasiment dans toutes les directions, à chaque fois on discute,
01:16 c'est microservices et découplage. Alors vous doutez bien que sur ce sujet-là, évidemment,
01:25 il a été largement analysé, mais ce qu'on peut constater c'est que les microservices qui existent
01:34 déjà, SSO, par exemple France Connect, Analytics, avec quelque part Vox l'usager, je donne mon avis,
01:41 on en est un, c'est assez étonnant parce que les partisans même des microservices ont le plus
01:46 grand mal, quand on leur demande d'utiliser celui-là, pourtant on a l'authentification,
01:50 on peut pas imaginer le microservice plus vu, revu et rabattu, eh bien ça va pas les empêcher de
01:59 nous dire "ah mais si je me mettais un petit cric dans le coin". Bon, ça prouve qu'il y a une petite
02:03 difficulté, c'est-à-dire que finalement il est interfacé, mais on préférait que ce soit le
02:08 sien plutôt que d'utiliser celui qui est déjà fourni dans un cadre plus général. En fait,
02:14 on perd de vue, avec toutes les histoires de microservices, tout simplement que ceux qui ont
02:18 inventé, en particulier Amazon, le concept, leur concept à eux c'était de dire "c'est découper
02:23 des gros services à la taille d'équipe, pour eux l'équipe, le mot d'ordre de Bezos c'est "il faut
02:30 que l'équipe puisse manger ensemble autour de deux pizzas". Là on n'est même pas sur notre sujet,
02:35 on est sur un sujet des gens qui ont des macro-projets encore plus gros. La réalité,
02:41 c'est que la modélisation, ce qu'on cherche, c'est pas des microservices, dans nos types de systèmes,
02:46 je parle pas forcément chez Amazon par exemple, mais dans nos types de systèmes, nos téléservices
02:54 qui correspondent à notre fonds de commerce, enfin en tout cas notre contexte d'emploi, c'est la
03:00 modulérisation, modélisation, modulérisation, c'est-à-dire qu'on veut pouvoir des modules et
03:03 pouvoir effectivement les faire un peu voler un tas et puis se dire "mais partir le jeu". Et ça
03:08 pour le coup tous les langages de programmation depuis les plus anciens, je veux dire même
03:13 Pascal, le turbo Pascal des années 90 avait la capacité à créer des packages, du coup vous
03:18 étonnez pas, dans le Java, dans tout ce que vous avez comme moderne, il y a la capacité à se bien
03:24 dire, de définir en loi les prototypes de fonctions, l'implémentation et voilà. Et par contre le coup
03:30 d'interconnexion à l'intérieur d'un environnement qui est traité dans un seul langage, il est quasiment
03:35 nul, là où dès que vous passez avec des microservices, vous faut à nouveau déclarer votre interface avec
03:40 un outil particulier, recompiculer, recompiler, recompiler avec du swagger, des choses comme ça,
03:45 et ainsi de suite. Donc s'il vous plaît, un peu de bon sens, dans nos contextes, vous pouvez déjà de
03:51 suite vous dire que la notion même de microservices, c'est plutôt un point à se dire "ouh là, celui
03:59 qui m'en parle, et ben va falloir le surveiller". Deuxième sujet qui revient régulièrement, c'est
04:06 les problèmes de disponibilité, et évidemment la réponse qui peut paraître la plus logique,
04:12 c'est de complexifier, complexifier en redondant, en remachinant, en ceci cela. Je ferai remarquer
04:20 deux choses, d'abord ceux qui ont le plus de retour d'expérience sur la disponibilité,
04:25 c'est les expérimentants. Donc le mieux c'est d'abord de leur demander, à eux en particulier,
04:31 une intégration avec les sauvegardes, avec le provisionning, avec la supervision, pour voir
04:36 comment le mettre. Et d'être eux-mêmes très très très très prudent, il y a une pratique qui s'appelle
04:42 les points de nouveauté, c'est d'être en gros, si dans votre patrimoine il y a N technologies,
04:45 vous pouvez en introduire une à la rigueur 2 dans une nouvelle technologie, à l'occasion d'un nouveau
04:51 produit ou projet, mais n'espérez pas tout refaire du sol au plafond. Moi aussi j'ai plein de bonnes
04:57 idées depuis que je suis arrivé ici, je peux pas, enfin on peut pas demander à un installement de
05:04 dire on va redévelopper en Rust, Golang et puis tout exploiter en X. C'est intéressant comme sujet,
05:11 c'est très très très intéressant, mais il se trouve que voilà, c'est pas réaliste tout simplement.
05:17 Autre exemple classique justement dans les choix technologiques et le voyage LG, énormément de
05:25 nos SI, on le voit quand on intervient, qu'on récupère un SI, on a l'habitude d'incorporer
05:36 des data stores, là on met les données de multiples sources, multiples versions. Alors
05:44 on met un petit MongoDB par là, un petit Elasticsearch, et des trucs plus sexy encore.
05:52 La réalité de nos produits, encore une fois c'est nos types, notre environnement, c'est que MongoDB
06:00 par exemple a beaucoup été créé parce que dans des environnements pour faire du suivi de publicité
06:06 et autres choses comme ça, il y a une grosse volumétrie parce que vous pensez même qu'il
06:09 s'agit d'enregistrer des clics ou des mouvements de souris, grosse grosse grosse volumétrie,
06:13 mais bon à la limite si on en perd trace de quelques unes voire quelques millions,
06:17 il n'y a pas mort d'hommes. Maintenant quand vous faites du transactionnel, d'accord en gros,
06:22 vous êtes en train de décrire quelqu'un que ce soit, je vous dis, quelqu'un qui fait un
06:28 registre de comment ça s'appelle, de comment ça s'appelle, de déclaration de produits dangereux,
06:39 d'impôts, de ce que vous voulez, dans tous les métiers de l'administration quasiment,
06:44 ouais c'est bizarre mais en fait la critère principale c'est l'intégrité, c'est-à-dire
06:51 qu'on vous donne un numéro et on ne le perd pas. On se doit d'assurer son intégrité dézonnée dans
06:58 le temps. Et tous les outils qu'on a parlé avant là, ils n'ont pas été conçus pour ça. Par contre
07:05 le SQL il a même tellement été conçu pour ça c'est que dans le modèle est inscrit le fait qu'il
07:09 y a même ce qu'on appelle la sérialisation des transactions, c'est-à-dire que du coup c'est
07:14 comme s'il y avait, il arrive à faire des requêtes en parallèle, mais c'est comme s'il y avait une
07:18 flèche du temps virtuelle dans laquelle on peut garantir que chacune des transactions se verrouille
07:24 pas. Il n'y a pas deux transactions qui chevrausent. Donc du coup les données sont cohérentes,
07:28 on ne perd pas, et en plus elles sont cohérentes entre elles par transaction. Et éventuellement on
07:32 peut annuler une transaction, ce n'est pas fini. Donc si vous avez les données, grosso modo on peut
07:42 discuter de savoir si c'est PostgreSQL, SQLite, DuckDB même pour d'autres usages plus d'analyse
07:49 de données. Mais voilà, c'est SQL. Alors certains se posent des questions en se disant "oui mais
07:56 alors est-ce que les performances et autres". Là on a un certain nombre de dossiers actuellement qui
08:02 sont des fois difficiles, on s'interroge sur les performances de la base de SQL. La réalité c'est
08:09 que c'est essentiellement des erreurs de débutants sur l'usage de l'emploi de SQL, parce que SQL
08:16 justement crée ce concept d'intégrité, de transaction, tout ça. Pour faire ça il nous
08:21 masque, heureusement pour nous d'ailleurs, il nous masque toute la réalité des index et tout ça. Bon
08:26 et bien de temps en temps on oublie des choses. Là vous voyez le rapport qui est passé entre mes
08:31 mains fait par Dalibo sur un SI. Il y a deux trois trucs qui ont été oubliés, c'est à dire que quand
08:38 on fait des injections de données en masse, les statistiques de la base en fait peuvent être du
08:44 coup biaisées et donc du coup on va pas chercher le bon plan de calcul, de l'exécution des requêtes.
08:50 À la fin il faut lui faire un analyse après chaque fois qu'il y a un bug. Il y en a d'autres qui sont
08:56 liées aux jointures, enfin quelques recettes de cuisine qui sont un peu oubliées. Alors l'autre
09:04 théorie qui est un versionnement qu'on pouvait trouver dans les projets open source, qui à mon
09:09 avis ne sont pas appropriés à notre contexte, qui sont appropriés à celles des projets open source,
09:12 mais pas à ceux-là, les projets open source prenons tout à l'heure Venman, pour avoir un
09:18 produit qui soit installable dans le plus de contexte possible, ont intérêt à se découpler
09:22 du moteur SQL, donc à en gros être compatible avec Postgre, avec MySQL, avec SQLite, etc.
09:27 En disant vous pourrez être amené à en changer. La réalité chez nous c'est qu'une fois qu'on a fait
09:33 un choix et qu'on a choisi en général Postgre, même pour DLR chez nous, il n'y a aucune raison
09:38 d'en changer, de toute façon dans 20 ans il y aura encore du Postgre ici. Donc autant l'assumer
09:44 pleinement. Donc le premier point qu'on a vu c'était une méthode, le choix de cette technologie,
09:49 maintenant il reste encore à développer.
09:51 [SILENCE]