Transcript de ma conférence « Des structures de données qui vont vous étonner »

En 2024-2025, j’ai présenté plusieurs fois ma conférence « Des structures de données qui vont vous étonner », où je parle de quelques structures de données, pour attirer l’attention des développeurs et développeuses sur le fait qu’il en existe beaucoup, qu’il est intéressant de savoir les choisir – et qu’on n’a pas toujours besoin de ré-inventer la roue.

Mon intervention a été enregistrée lors de mon passage à PyConFR 2025 :

Comme tout le monde n’accroche pas avec le format vidéo et que beaucoup préfèrent du texte, voici une tentative de transcript de cette conférence.

Vous trouverez en-dessous de chaque slide le texte qui lui correspond, parfois enrichi d’informations que je n’ai pas données lors de la présentation ou qui ne sont pas visibles dans les slides – parce qu’elles sont passées par ma gestuelles ou par des animations / transitions invisibles avec ces images figées. Le style est volontairement proche de l’oral.

Bonjour 👋.

Aujourd’hui, pendant les 20-25 prochaines minutes, je vais parler un petit peu de structures de données.

Et je pars d’il y a 25 ans maintenant, je me vieillis un petit peu : j’étais à la FAC à l’autre bout de Lyon… Et des structures de données, quand on est à la FAC, on en voit plein. On voit ce genre de choses : des arbres, des files, des piles, des graphes, des tables de hachage… Enfin plein de trucs assez sympas !

Mais en parallèle de voir ces trucs, on nous apprend qu’on choisit souvent nos structures de données en fonction de leur complexité et des algorithmes qu’on va leur appliquer.

C’est quelque chose qui s’exprime avec la notation “grand O”. Globalement, quand on a n éléments dans une structure de données, O(1) (à l’oral : “O de 1”) signifie en une opération ou en nombre d’opérations constants, alors que O(n) signifie en ordre de n opérations.

Et vous comprenez assez vite que quand on a 10 millions d’éléments à manipuler, eh bien O(n) est plus efficace que O(n²), qui est moins efficace que O(log(n)) par exemple. Plus on est haut, moins on est efficace.

Et on étudie fréquemment à l’université des structures de données un peu classiques : des tableaux, des listes chainées, ce genre de choses. Et on connaît leurs complexités moyennes. Parfois elles sont faibles, parfois elles sont plus élevées.

Par exemple, accéder à un élément d’un tableau, c’est ordre de constante, c’est quelque chose de très rapide. Insérer ou supprimer un élément dans une table de hachage, là aussi, c’est rapide. Par contre, rechercher un élément dans un tableau demande de le parcourir en entier. C’est moins rapide.

Alors, pourquoi est-ce qu’on s’embête avec ça ?

Eh bien, on s’embête avec ça parce qu’on veut travailler avec des structures de données qui nous permettent d’être efficaces pour les besoins de chacune des applications qu’on va développer.

Et quand on regarde Wikipédia, qu’on va à la page “liste de structures de données”… On commence à scroller un petit peu, et en fait, on scrolle pendant assez longtemps : des structures de données, il y en a un sacré paquet !

Donc là, on pourrait en parler pendant une année universitaire à peu près, mais on n’a pas le temps aujourd’hui.

Un peu de curiosité quand même aujourd’hui : on va découvrir trois structures de données. Trois structures de données qui répondent à des besoins d’applications, comme on peut en manipuler tous les jours, que ce soit en utilisateur/utilisatrice, ou en tant que développeur et développeuse.

Et la première, justement… Développeur, développeuse, on travaille avec des éditeurs de textes au quotidien. On tape du texte ou on supprime du code. Je vous souhaite de supprimer beaucoup de code.

Et même nos collègues, non développeurs/développeuses, ils/elles vont aussi écrire du texte : des mails ou des prompts dans ChatGPT.

Si on part de cette phrase : "une souris dans l'herbe", et qu’on a notre curseur qui est placé avant le mot "dans", on va vouloir insérer du texte, placer le mot "verte" après "souris", avant "dans l'herbe".

Donc qu’est-ce qu’on fait ?

On alloue un nouvel octet tout à la fin de la chaîne, en gris clair, là-bas le point qui est apparu, et on va réallouer de la mémoire. Une opération qui peut prendre un petit peu de temps.

Et ensuite il va falloir déplacer tous nos caractères vers la droite, …

… un par un, …

(quelques décalages de plus…)

… pour que cet octet libre arrive à la bonne position : la position de notre curseur.

Et là ça y est, on peut insérer notre caractère : "une souris [v]dans l'herbe".

Mais quand même, avec l’approche qu’on vient de voir, à chaque fois qu’on veut insérer un caractère, on fait une réallocation mémoire et on décale tous les caractères un par un. Ça prend beaucoup de temps.

Et plus notre texte va être long, plus on va avoir de caractères à décaler. Donc si on édite un document qui fait 50,000 mots parce que vous écrivez une nouvelle, je vous souhaite d’écrire plutôt à la fin plutôt qu’au début.

Donc autrement dit, insérer un caractère, c’est plein de décalages de caractères encore et encore et encore. C’est extrêmement lent… Et on ne fait bien sûr pas ça dans la vie de tous les jours !

Heureusement, on fait plus efficace.

Donc on repart.

Mon texte initial, le curseur placé avant "dans", et je veux insérer du texte à cet endroit-là.

Je vais allouer plusieurs octets d’un seul coup : j’agrandis mon espace mémoire.

Puis, comme tout à l’heure, je vais décaler le texte caractère par caractère pour que le buffer que j’ai réalloué vienne se placer au bon endroit.

(…)

(quelques décalages de plus…)

J’ai fait un pari : je me dis que, probablement, si je veux insérer un caractère, je vais vouloir insérer plusieurs caractères. Donc j’ai alloué d’un seul coup plusieurs espaces.

Et puis là, je peux commencer à insérer du texte : "v".

Et notez en vert au-dessus de la chaîne de caractères, vous avez un pointeur vers le début du buffer libre, et en rouge en dessous de la chaîne, vous avez un pointeur vers la fin de la position.

OK, donc pour insérer notre caractère, on décale le pointeur du haut et on met du texte à l’emplacement pointé.

(quelques insertions de plus…)

Et ça marche très bien en insertion… Mais, si on se rend compte qu’on a fait une erreur, qu’on a mis une espace au lieu de mettre une virgule, ça va aussi marcher en délétion.

Je recule un pointeur d’une position, …

… j’insère ma virgule …

… et je recommence à insérer du texte.

(quelques insertions de plus…)

Au bout d’un moment, malheur : plus assez d’espace mémoire, je ne peux plus insérer de texte alors qu’on n’est pas encore arrivé à la fin de la phrase. Et bien qu’est-ce qu’on fait?

On va agrandir à nouveau mon espace mémoire. Donc je réalloue un bloc de mémoire à la fin, …

… puis je redécale cet espace pour qu’il arrive à la position de mon curseur, …

(quelques décalages de plus…)

… et, au bout d’un moment, je peux recommencer à insérer du texte.

(…)

(quelques insertions de plus…)

Voilà, j’avais fait des calculs pour ne le faire que deux fois, parce que sinon la démo est un peu longue.

Notre curseur, il est à cet endroit-là (la flèche orange) : il est au début du buffer vide au milieu.

Et bien sûr, cet espace mémoire qui reste aux 3 octets vides au milieu, on l’affiche ici parce qu’on travaille et on veut voir où ils sont. L’affichage dans votre éditeur de texte, on ne va pas afficher ces 3 octets vides. On triche un petit peu à l’affichage.

Cette structure de données, elle s’appelle un Gap Buffer :

On alloue de l’espace mémoire pour plusieurs caractères à la fois. Puis on décale une seule fois.

Donc : on fait une allocation de temps en temps, on ne fait pas des décalages à chaque fois qu’on veut taper un seul caractère. On fait ça de façon beaucoup plus efficace que précédemment.

Cette structure de données est plus vieille que moi : elle date du début des années 1970. Et c’est utilisé dans Emacs.

Quelque chose d’assez sympa.

Bien sûr, on n’utilise pas des Gap Buffers pour tout : c’est adapté dans certains cas et pas dans d’autres cas. Et d’autres approches vont peut-être, parfois, être plus adaptées pour cette problématique d’édition de texte.

Et notamment, on peut imaginer représenter un texte sous cette forme-là. Ce que vous avez ici, c’est une “Rope”, une “corde” en français. C’est un arbre binaire, où chaque feuille de l’arbre contient une chaîne de caractère de petite longueur : plus facile à manipuler qu’un texte entier.

Chaque nœud porte la somme des poids de toutes les feuilles au-dessous à sa gauche. Donc 4, 4, 9… Ainsi, chaque nœud divise la chaîne en deux sous-arbres qui contiennent partie gauche et partie droite.

L’avantage de ça, c’est qu’on n’a pas besoin d’un gros espace mémoire qui contienne l’intégralité de mon texte. Donc ça peut travailler plus facilement sur des devices un petit peu limités.

Et en plus, si on manipule bien, on peut permettre les annulations. Alors que sur la structure de données précédente, on ne pouvait pas.

Donc ça peut être assez sympa.

Ou alors, une autre structure de données utile pour manipuler du texte, c’est la “Piece Table”, peut-être “Table de pièces”, en français approximatif. Ça, c’est utilisé dans Visual Studio Code.

Le principe d’une Piece Table, c’est qu’on a deux buffers : buffer d’origine, buffer d’ajout.

On retrouve dans le buffer d’origine mon texte initial, qu’on ne va jamais modifier. Et ensuite, je vais faire de l’append, des ajouts, dans le Add buffer. Et je vais construire une table de rapièçage pour remettre ensemble ces deux chaînes de caractères.

Par exemple, ici je vais dire, “prends 11 caractères dans l’original buffer, puis prends 13 caractères en commençant la position 7 dans le buffer d’ajout, et termine avec 12 caractères à partir de la position 11 du buffer d’origine”. Et si je ne me suis pas planté dans mes calculs parce que je l’ai fait à la main, on obtient normalement une chaîne de caractères qui correspond à quelque chose que vous connaissez de votre enfance.

On va passer à un deuxième use case, un deuxième cas un peu sympa : identifier une donnée qu’on a peut-être déjà vue, probablement déjà vue.

Le cas d’usage qu’on va faire pour cet exemple, c’est celui-là : j’ai un texte qui parle d’animaux. Et j’aimerais savoir, quand je lis ce texte, ou plutôt quand je vais lire le texte suivant, que je vous présenterai par la suite, si j’ai déjà rencontré ces animaux.

L’approche un peu naive, c’est parcourir ce texte et stocker en mémoire la liste des animaux au fur et à mesure que je les croise.

Donc un canard ça prend au minimum 6 octets, un cygne ça en prend 5, un chat ça en prend 4. Autrement dit, pour garder en mémoire le fait que j’ai déjà vu ces trois animaux, j’ai besoin de 15 octets.

Sur un texte qui fait moins de trois lignes, 15 octets, on peut se dire que c’est pas beaucoup. Mais au fur et à mesure qu’on va lire de plus en plus de livres, ça va faire bien plus de 15 octets. Donc, peut-être pas optimal.

Et si on se lançait un défi? Si on se disait, au lieu d’utiliser 15 octets ou plus pour stocker ces animaux et peut-être d’autres, si je me limitais à 2 octets?

OK, 2 octets. Je les représente sous forme de 4 quartets, ça s’appelle des quartets en français, des nibbles en anglais, du verbe grignoter.

Et je vais lire mon texte. Donc je passe en phase de construction de ma structure de données sur 2 octets.

Je vois le mot "canard".

Au lieu de stocker le mot "canard", je vais lui appliquer une fonction de hachage qui me donne un hash sur deux octets. Dans ce hash, j’ai des bits à 1.

Je vais prendre ces bits à 1 et je vais les répercuter dans ma structure de données.

Je continue à lire mon texte, j’arrive sur le mot "cygne".

Le mot "cygne", de la même façon, je lui applique la même fonction de hachage. J’obtiens des bits à 1, je les répercute dans ma structure de données.

On continue à lire mon texte d’origine. J’arrive sur le "chat", pareil, fonction de hachage, je récupère des bits à 1, je les stocke dans ma structure de données.

Donc là, j’ai une structure de données sur deux octets qui contient des bits à 1 et des bits à 0.

Je découvre maintenant un nouveau texte et je veux savoir si j’ai probablement déjà vu les animaux qui sont dans ce texte.

Eh bien, qu’est-ce que je vais faire ? Je vais passer en phase d’utilisation de ma structure de données.

Je repars de ma structure de données dans laquelle j’ai des bits à 1 suite à la phase d’alimentation qu’on a fait précédemment. Et je vais commencer à lire mon second texte.

Dans le second texte, j’avais un "canard". Je lui applique la même fonction de hachage que celle que j’avais manipulée précédemment. Ça me donne des bits à 1.

Je vais comparer ces bits à 1 avec ceux qui sont dans ma structure de données. Tous les bits à 1 du hash de "canard" sont à 1 dans ma structure de données. Je sais donc que j’ai probablement déjà vu un canard.

On continue à lire le deuxième texte.

J’arrive sur le mot "pigeon". Même chose, je lui applique la fonction de hachage. J’ai des bits à 1. Je compare avec ma structure de données sur deux octets. Et je vois qu’un des bits à 1 dans le hash de "pigeon" n’est pas à 1 dans la structure de données.

Je sais donc affirmer avec certitude que je n’ai jamais rencontré de pigeon.

Puis je passe au troisième animal de mon nouveau texte, le mot "chien". Je lui applique la fonction de hachage, j’ai des bits à 1, je compare avec ma structure de données. Tous les bits à 1 dans le hash de "chien" sont à 1 dans ma structure de données.

J’affirme donc, je crois que j’ai déjà vu ce mot, je crois que j’ai déjà rencontré un chien.

Sauf qu’on n’a pas vu un chien dans le premier texte, on a un faux positif.

La structure de données qu’on voit là, c’est un Bloom Filter. Ça date de 1970. C’est hyper efficace pour insérer des éléments dedans et les rétriever. O(1), globalement, on l’a vu.

Et sa particularité est d’être une structure de données probabiliste.

• Un Bloom Filter, ça nous permet des faux positifs. Quand on dit “la donnée est présente dans la structure”, on se trompe peut-être, comme on l’a fait pour le chien.
• Par contre, ça ne permet pas de faux négatifs. Quand je dis “la donnée n’est pas connue”, je suis certain qu’elle n’est pas connue.

Et ça peut avoir plein d’usages dans la vie réelle. Vous en utilisez certainement tous les jours sans même vous en rendre compte.

Par exemple, dans un navigateur…

Vous savez, quand vous tapez une adresse là-haut dans la barre d’adresse du navigateur, le navigateur va essayer de vous dire si cette adresse est malicieuse ou non.

Alors on pourrait imaginer embarquer dans le navigataire la liste de tous les noms de domaines malicieux de la Terre, mais il y en a énormément. Difficile de trouver des estimations, mais ça va faire pas mal de gigaoctets si on veut la liste de tous les noms de domaines malicieux. Et ça ne va pas rentrer dans votre téléphone s’il date de plus de 5 ans. Donc pas vraiment une bonne approche.

À la place, un Bloom Filter peut être une bonne approche : on va essayer de résumer tous les noms de domaines malicieux en un certain nombre d’octets. Et c’est ce qui a été fait pendant plusieurs années dans Firefox ou dans Chrome : un des deux utilisait un Bloom Filter pour ça.

Maintenant, à la place, j’imagine qu’on fait des appels d’API chez Google, et comme ça, Google suit votre navigation.

L’autre approche, c’est sur un CDN, un système de serveurs qui distribue du contenu. On se dit, une fois qu’on a généré du contenu, on veut le mettre en cache sur le CDN au plus proche des utilisateurs, pour le resservir encore et encore sans le régénérer. Et c’est une idée qui est très bonne.

Mais à une époque, le CDN Akamai a fait une étude, et ils se sont rendus compte que 75% des URL qui étaient appelées sur leur CDN n’étaient appelées qu’une seule fois. Autrement dit, s’ils mettaient en cache dès le premier appel, ils gaspillaient trois quarts de l’espace mémoire de leur CDN.

Donc ils se sont dit, on va stocker les appels qui ont déjà été faits dans un Bloom Filter, et on va ne mettre en cache qu’au second appel. Autrement dit, quand une donnée est probablement déjà présente dans le Bloom Filter = quand on est probablement sur le second appel.

Et puis pour des développeurs, développeuses, quelque chose qui vous parlera un peu plus : avant d’aller charger une donnée via un système un petit peu coûteux, genre un appel d’API qui prend des dizaines ou des centaines de millisecondes, ou une requête sur une base de données qui est peut-être un petit peu complexe qui va mettre un petit peu de temps, eh bien, savoir si la donnée existe probablement, ça va nous permettre de faire l’appel pour de vrai.

Alors que savoir que la donnée n’existe certainement pas, juste on ne fait pas l’appel. C’est quelque chose qui est implémenté dans certains cas dans PostgreSQL et dans Cassandra : on ne fait pas des appels au disque si on n’a pas besoin de les faire.

Et puis dernier cas que je connais bien, je travaille dans le streaming vidéo. Certaines plateformes mémorisent les vidéos que vous avez déjà vues pour ne pas vous les recommander à nouveau. Un Bloom Filter, ça peut être une approche plutôt efficace.

C’est aussi ce que faisait Medium il y a quelques années : ils avaient documenté qu’ils utilisaient un Bloom Filter pour stocker la liste des articles que vous avez probablement déjà vus et ne pas vous les recommander à nouveau. Au pire (= faux positif), ils se trompent de temps en temps, ils ne vous recommandent pas certains articles, ce n’est pas très grave.

Bien sûr, ce que je vous ai présenté avec mes hashes et mes deux octets, c’est un petit peu simplifié. Dans la vraie vie, on va utiliser plusieurs fonctions de hachage. Ça va permettre de réduire un peu le nombre de faux positifs tout en restant sur peu de bits.

Et si vous vous dites, “c’est quoi le taux de faux positifs, le nombre de bits et machin?”

Attention, c’est effrayant…

Vous avez ces formules mathématiques qui sont ici :

• n, c’est le nombre d’items dans le filtre ;
• p, c’est la probabilité de faux positifs ;
• m, c’est le nombre de bits dans le filtre ;
• et k, c’est le nombre de fonctions de hachage.

Et c’est un peu tout en fonction les unes des autres. Donc, vous choisissez ce que vous voulez optimiser. Oui, c’est compliqué.

Si on veut un exemple : un million de clés, une chance sur mille de faux positifs, six fonctions de hachage, ça vous donne un Bloom Filter qui fait 1.88 mégaoctets, quelle que soit la taille des éléments. Que ce soit des noms de domaines qui font 20-30 octets, que ce soit des URL vers des articles de blogs.

Bien sûr, il existe des évolutions au Bloom Filter. Il en existe plus d’une soixantaine. Donc rien que pour ça, vous allez pouvoir lire Wikipedia pendant un petit moment. On ne va pas toutes les passer en revue, je vais vous en montrer deux.

La première, c’est un Counting Bloom Filter, ça date de l’an 2000.

Un inconvénient du Bloom Filter, c’est qu’une fois qu’on a insèré des éléments dedans, on ne peut pas les supprimer puisqu’on passe des bits à 1 dans la structure de données. Avec un Counting Bloom Filter, au lieu d’utiliser des bits à 0 ou 1, on stocke des compteurs et on peut donc supprimer des éléments en désincrémentant ces compteurs.

Et l’autre, le Filtre Coucou, il est sympa parce qu’il a moins d’overread que Bloom Filter notamment quand on stocke beaucoup d’éléments et qu’on veut un taux assez faible de faux positifs. Je ne suis pas sûr de réussir à vous l’expliquer en moins de 25 minutes, donc pareil : Wikipédia ;-)

Et puis, dernier use case.

Je montre mon âge à nouveau, vous vous souvenez un petit peu de ces vieux téléphones ? On tapait trois fois ou quatre fois pour réussir à avoir certaines lettres, c’était un petit peu fastidieux. Donc on était assez content quand on avait de la saisie prédictive ou de la correction d’orthographe.

Une façon un petit peu naïve d’implémenter ces systèmes, c’est de stocker toute la liste de tous les mots et de tous les non-mots en mémoire.

Donc on va stocker tout un dictionnaire sous forme d’un arbre. Chaque niveau de l’arbre, c’est une lettre qu’on ajoute à la fin d’un début potentiel de mots. Et c’est un sacré bordel.

VIDE, c’est un mot qui existe en français. Je symbolise ça avec un dollar vert à la fin pour dire que VIDE, c’est un mot entier.

Par contre, VIDEA, VIDEB, VIDEC, ce ne sont pas des mots entiers, donc pas de dollars.

Et on stocke toutes les possibilités. On va jusqu’à VIDEN, VIDEO, qui est un mot entier, VIDEP, VIDEQ, et ainsi de suite.

Si je reviens à gauche et que je me concentre sur VIDEA, …

… par exemple, en dessous de VIDEA, je vais stocker VIDEAS, VIDEAST, VIDEASTE, qui est un mot entier, VIDEASTES au pluriel, qui est aussi un mot entier, et à côté, toutes les possibilités de mots et de non-mots.

Ça fait pas mal d’occupation mémoire.

Pareil, il y a l’autre bout, en dessous de VIDEO, qui est un mot entier.

Je vais stocker VIDEOC, VIDEOP, VIDEOPR, VIDEOPRO, VIDEOPROJ, VIDEOPROJECT, VIDEOPROJECTEUR qui est un mot, VIDEOPROJECTION et VIDEOPROTECTION qui est aussi un mot de même longueur.

Et je pourrais même avoir VIDEOPROJECTEURS au pluriel en-dessous, avec un niveau d’arborescence de plus.

Et là aussi j’ai toutes les autres possibilités et il y en a tellement à l’écran que je vous ai épargné certains niveaux et j’ai mis des petites étoiles parce que ça ne tenait pas sur le slide. C’est un peu la foire.

Eh bien, cette structure de données, ça s’appelle un “Trie” (ℹ️ ça s’écrit “Trie” mais ça se prononce “Try”).

Oui, prononcé Try, alors que ça vient du mot retrieval (ℹ️ d’où la manière dont ça s’écrit). Mais on dit souvent Try pour ne pas confondre avec Tree, un arbre, mais c’est aussi un arbre, donc vous prononcez bien comme vous voulez, en vrai. Voilà, bon courage.

Ça date de 1960, le Trie.

Et quand on a un Trie qui contient tous les mots et les non-mots qui existent en français, ça devient assez facile de faire de la vérification d’orthographe.

Par exemple, on tape VIDEO.

VIDEO, c’est un mot entier. Il est valide.

VIDEOP, par contre, c’est un début de mot possible puisqu’il y a des choses en dessous dans l’arbre, mais ce n’est pas un mot entier.

Et on continue à taper des lettres.

Pour aller jusqu’à VIDEOPROJECTEUR, on est encore passé par des débuts de mots qui existent. Et VIDEOPROJECTEUR, c’est aussi un mot entier.

Et puis on pourrait continuer avec un niveau au-dessous et des VIDEOPROJECTEURS au pluriel.

Pareil à l’autre bout de l’arbre. N’oubliez pas qu’on a absolument tout en mémoire. Donc ça consomme pas mal de mémoire.

Vu que ça consomme pas mal de mémoire, il existe des évolutions au Trie.

Et la plus connue, c’est celle-ci : le Radix Tree ou arbre compressé. Je n’ai jamais vu “arbre compressé” dans ma vie mais il parait que ça se dit aussi. Et ça date de 1968.

Un Radix Tree, ça ressemble à ça, c’est les mêmes données que précédemment. On a regroupé tous les nœuds qui ont un seul enfant, on les a fusionnés, on a supprimé tous les non-mots, bref on a fait beaucoup de ménage.

On a supprimé donc tout ce qui était inutile en mémoire, on gagne beaucoup en espace mémoire, on gagne aussi en profondeur de l’arbre, donc on va passer moins de temps à aller petit à petit au fond de l’arbre quand on veut vérifier un mot, puisque là on n’a que 5 niveaux au lieu des 10 ou 12 qu’on avait tout à l’heure.

Et quand on a notre arbre en mémoire, et bien VIDEASTE, on trouve assez facilement, …

… ou VIDEOPROJECTEUR, on le trouve aussi assez facilement, et c’est un mot qui existe.

On peut faire de la vérification d’orthographe, c’est ce que j’ai fait dans les deux exemples que je vous ai montrés, on trouve des mots qui existent. On peut aussi faire de la saisie prédictive, en se disant qu’en dessous de VIDEOPROJECT, il existe encore des choses.

On peut aussi peut-être enrichir cet arbre avec des pondérations, pour indiquer que, probablement, on veut plutôt taper VIDEOPROJECTEUR que VIDEOPROJECTION, ce genre de choses.

On approche de la fin du temps qui m’était alloué : je vois les compteurs de minutes qui descendent …

… et, qu’est-ce que je voulais vous dire aujourd’hui ?

Je voulais vous dire qu’il existe des trucs cool en informatique, y compris depuis les années 70, y compris depuis les années 60 même.

Désolé, le slide vous ment : cette disquette là, ça date des années 80 et il fallait remonter aux disquettes 5"1/4 pour les années 70, mais je n’ai pas trouvé de jolies photos… Et les miennes sont dans le grenier chez mes parents et je n’ai pas eu le courage d’aller y fouiller pour en ressortir.

Autrement dit, ne réinventons pas la roue.

Il existe plein de structures de données. Oui, vous allez passer beaucoup de temps sur Wikipédia pour les chercher ou vous allez demander à ChatGPT “qu’est-ce qui répond à ma problématique?”. Peu d’occupation mémoire, itération rapide, ce genre de choses.

Et ce que j’aime dire, c’est qu’assez souvent, plutôt de réinventer la roue, savoir choisir la bonne forme de roue, celle qui est adaptée à nos besoins, ça fait partie des compétences nécessaires dans nos métiers.

La roue carrée et la roue triangulaire, ok, elles vont assez rarement nous servir. La roue ronde, elle va très certainement très souvent nous servir. Mais dans certains cas, une roue crantée, ça sera vachement plus adapté à vos besoins.

Et oui, vous avez dû attendre mon avant-dernier slide pour voir mon adorable chaton, Bucket.

Ça faisait trois semaines que je l’avais trouvée, quand j’ai pris cette photo. C’était encore un tout petit chaton très curieuse, et quelques années après, elle est toujours un peu curieuse, des fois un petit peu trop.

Mais voilà : soyez curieux, un peu de curiosité, c’est très cool dans nos métiers !

Je m’appelle Pascal MARTIN, j’ai pendant longtemps été développeur avec PHP et son écosystème. J’ai été lead DevOps, je suis désormais Principal Engineer chez Bedrock. Je suis aussi AWS Hero.

J’ai fait du Python la semaine dernière quand même, avant que vous commenciez à balancer les tomates, parce que c’est un très bon langage pour mettre d’accord les collègues qui font du JS, du Go et du PHP, qui me disent “moi je veux des exemples dans mon langage, je ne comprends pas les autres”. Et bien, on leur file du Python, ils comprennent très bien les exemples. Donc, merci Python ❤️.

Et je vous souhaite d’être curieux, curieuses, et de vous amuser.

J’ai donné cette conférence plusieurs fois – et je serais très heureux de la redonner, c’est un sujet que j’aime beaucoup… Vous savez où me trouver ;-)

Je n’apprends jamais mon discours par cœur et j’ai toujours quelques variations mineures entre deux déroulés, mais ce que j’ai noté ici doit être assez proche de ce que j’ai dit à PyConFR en 2025.