Salut et bienvenue dans ce nouvel épisode du podcast de Codes Garage,
je m'appelle Nicolas Bernard Bernard et aujourd'hui,
on va parler du concept d'immutabilité des données en programmation.
Alors en informatique, l'immutabilité, c'est un concept clé
quand on parle de stockage et de traitement des données.
Une donnée immutable, on peut aussi l'appeler immuable en français,
c'est une donnée qui ne pourra pas muter,
c'est-à-dire qu'elle ne pourra pas changer jamais,
ni être modifiée, ni être détruite.
Alors où est-ce qu'elles sont utilisées ces données ?
En réalité, les données immutables sont indispensables dans notre monde numérique,
mais aussi dans notre monde physique,
et permettent d'avoir une source de vérité sur laquelle s'appuyer
pour prendre des décisions importantes à partir de données fiables,
figées dans le temps et non-facifiées.
Alors où est-ce qu'on peut retrouver ce genre de données ?
Eh bien partout.
Un acte de vente pour un bien immobilier,
c'est un document immutable une fois qu'il est signé.
Une facture en comptabilité, c'est immutable.
Le montant, le destinataire et l'origine d'un virement bancaire,
ce sont des données immutables.
Le contenu d'une RFC, un document de spécification technique
dont on a déjà parlé dans un précédent épisode, il est immutable.
C'est également le principe d'immutabilité
qui rend le concept de blockchain si puissant.
Parfois, l'immutabilité d'une donnée ou d'un document,
il est assuré de manière technique,
c'est le cas de la blockchain qui va assurer l'authenticité
et l'imutabilité des transactions
grâce à son contrôle des haches de chaque bloc précédent.
Alors si jamais le sujet des blockchain vous parle pas trop,
vous pouvez aller écouter notre épisode précédent
sur l'introduction justement à la blockchain.
Alors je sais ce que vous pensez.
Comment est-ce qu'on fait si on a besoin de changer la valeur
d'une donnée immutable ?
Évidemment, la réponse simple, c'est pas possible.
Mais en réalité, c'est pas grave.
Parce qu'on ne va jamais changer directement notre donnée,
mais on va venir y associer des changements.
Alors je sais que la frontière a peu paraît très mince
et pourtant, ça fait toute la différence.
Si on prend un exemple concret, qui est la comptabilité.
Alors ne partez pas, vous allez voir, c'est très très très simple.
En comptabilité, une facture émise par une entreprise est immutable.
Elle ne peut être ni annulée, ni supprimée, ni modifiée.
Pourtant, on le sait, l'erreur est humaine,
donc vous pouvez très bien faire une grosse erreur
lorsque vous créez votre facture.
Imaginons qu'au lieu de facturer 1 000 € à un client,
vous disait d'y t'est une facture de 10 000 €.
Si une facture n'était pas immutable,
on pourrait la détruire et en recréer une autre très facilement.
Sauf que ça ouvrirait la porte à la fraude, aux factures fantômes,
et ça ferait que la comptabilité ne serait plus aussi authentique.
Alors comment faire pour corriger son erreur ?
Eh bien, ça se passe en trois étapes.
D'abord, on va garder notre facture erronée.
Ça va être une facture officielle.
Ensuite, on va créer un document qui s'appelle un avoir.
C'est comme une facture, mais avec un montant négatif,
en l'occurrence, du montant exact que notre précédente facture,
ce qui va avoir pour effet d'annuler la somme qui est due par le client,
qu'on appelle la créance.
Et enfin, on va recréer une facture
avec le bon chiffre que le client devra payer.
On crée une facture, on se trompe,
on crée un avoir qui est du montant inverse exact
de la première facture,
et on recréait une dernière facture avec le bon montant.
Si on est réfléchi, chaque document comptable et immutable,
on peut corriger ses erreurs,
modifier l'état final de notre transaction avec notre client,
mais notre historique de modification
sera toujours authentique et surtout vérifiable.
En l'occurrence, c'est notre logiciel comptable
qui va en partie assurer cette immutabilité
en empêchant les modifications et les supprécions
des documents qui ont été validés.
Pour un acte de vente, par exemple, comme en immobilier,
ce sera le rôle du notaire de vérifier
que tous les actes précédents se suivent
avec les noms des acheteurs et des vendeurs,
et créera un nouvel acte de vente pour une nouvelle transaction.
Donc voilà, on a parfois des vérifications logicielles,
des vérifications humaines,
mais le concept d'immutabilité est toujours le même.
Pour revenir dans notre monde informatique,
on a évidemment certains langages de programmation
qui nous permettent de créer des constantes immutables,
c'est-à-dire qu'on va y assigner une valeur
et on ne pourra plus jamais changer cette valeur.
Si on veut réutiliser cette valeur et la changer,
il faudra recréer une autre variable
basée sur notre première variable qui est immutable.
Mais quand on parle de stockage des données,
on pense tout de suite à une base de données.
Il existe des bases de données
qui fonctionnent sur ce principe de données immutables et d'historique.
C'est ce qu'on appelle de l'event sourcing,
ou en français on peut dire approvisionnement d'événements,
même si ça ne s'utilise pas beaucoup.
Et en réalité, au lieu de stocker des données dans une table,
comme on ferait avec une base de données MySQL classique par exemple,
on va prendre le cas d'une table avec des utilisateurs.
En base de données classiques, relationnelles,
on viendrait avec des requêtes,
altérer le contenu de la table
pour créer, modifier, supprimer des utilisateurs.
Et bien là, avec de l'event sourcing,
la seule chose qu'on va avoir le droit de faire,
c'est d'empiler des événements sous la forme de commande.
On va avoir deux possibilités,
ajouter une ressource ou ajouter une modification d'une ressource.
Par exemple, on va empiler les événements suivants.
J'ajoute un utilisateur qui va s'appeler John Doe.
Ensuite, j'ajoute la modification de son âge avec la valeur 25.
Puis, j'ajoute la modification de son âge encore avec la valeur 35,
parce que je me suis trompé la première fois,
que l'utilisateur s'est trompé,
mais l'état précédent est quand même accessible dans la base de données.
Puis enfin, je ne peux pas supprimer mon utilisateur,
on se rappelle,
une donnée immutable, on ne peut pas la supprimer,
mais je peux le marquer comme supprimer avec un nouvel événement.
Donc j'ajoute un événement de modification
de l'état de mon utilisateur qui sera marqué comme supprimer ou désactiver.
C'est ce qu'on appelle aussi le soft delete.
Ça, on en a parlé aussi dans un épisode pressionnel.
Evidemment, là, je vous présente un exemple très simple,
mais en réalité, il faut faire très attention,
parce que, comme je l'ai expliqué avant,
une donnée entente sera toujours dans l'historique,
ce qui n'est pas forcément compatible
avec la protection des données personnelles dans le cas des utilisateurs.
Mais par contre, dans énormément de cas d'utilisation,
l'event sourcing est une stratégie de stockage de données
qui peut être très, très puissante.
Alors le dernier cas que vous côtoyez sûrement tous les jours,
c'est le fonctionnement de Git.
Sur Git, chaque nouvelle version du code
n'est en réalité qu'une liste de modifications
entre l'ancienne version et la nouvelle version,
avec les ajouts, les suppressions et les modifications
qui sont stockées dans l'historique.
Mais si je vous ajoute un jour l'historique des versions infichiers,
eh bien même si plus tard vous supprimez ce fichier,
il restera toujours dans l'historique
avec l'ensemble des modifications
qui y a eu sur ce fichier avant qu'il soit supprimé.
Donc là, ce ne sont pas les fichiers qui sont immutables,
évidemment, ce sont chaque version du logiciel.
Alors vous pouvez évidemment dans Git
remonter avant l'ajout, modifier l'historique,
en forçant Git à modifier l'historique,
parce que l'objectif de Git,
ce n'est pas d'être une source de vérité légale du code, etc.,
mais c'est simplement de faciliter la gestion de version.
Donc là, en l'occurrence, l'immutabilité,
c'est un moyen pour y parvenir,
mais ce moyen-là, il peut être contourné.
C'est là aussi où il faut faire attention
quand on parle de données immutables,
ou de documents immutables,
c'est qui est-ce qui fait la vérification
que notre données ne va jamais être changée.
Est-ce que c'est quelque chose de logique, d'informatique
et qu'on ne peut absolument pas contourner ?
Est-ce que c'est un humain qui peut faire aussi des erreurs ?
Les notaires, les banquiers peuvent faire des erreurs,
mais en théorie ne devrait pas.
Ou est-ce que c'est quelque chose un petit peu entre les deux,
comme Git, ou ça peut être contourné,
mais ce n'est pas forcément l'objectif premier.
J'espère que cet épisode sur l'immutabilité des données
vous aura appris quelque chose.
Si c'est le cas et que vous avez apprécié l'épisode,
n'oubliez pas d'ajouter cinq étoiles au podcast,
sur Apple Podcast, Google Podcast,
Spotify, Deezer, peu importe.
En tout cas, ça permet de faire remonter le podcast
dans les résultats et ça nous permet vraiment
de toujours avoir envie de vous en donner encore plus
et de faire des épisodes encore plus complets
et encore mieux travaillés.
Je vous donne rendez-vous la semaine prochaine
pour un prochain épisode du podcast,
ou directement sur code-garage.fr
pour retrouver tous les articles de blogs,
tous les épisodes du podcast
et évidemment tous nos cours complets.
Avec l'abonnement, vous pouvez accéder absolument à tous
les cours, les exercices, les quizzes.
Donc à la semaine prochaine pour un prochain épisode.
Salut !