🧠 Mémoire : ce qui rend la suite possible

le 8 novembre 2026

Du logiciel à l'IA, des jeux vidéo à la musique et à l'image : ce que nous conservons pour continuer à créer.

Introduction

Que faut-il conserver pour que quelque chose puisse continuer ? Une décision dont on a oublié la raison, un calcul à reprendre, une mélodie reconnue : la question traverse le développement, le jeu et la création. Dans Darkwood, la mémoire prend des durées et des supports différents. Certaines données accompagnent une opération puis disparaissent ; d'autres doivent rester compréhensibles longtemps après leur création. Les expériences réunies dans Darkwood Memory rendent ces différences manipulables. Elles explorent un même passage : garder assez du passé pour pouvoir décider de la suite.

Darkwood — La mémoire des connaissances

Reprendre un projet commence souvent par une enquête. Le code fonctionne, un document donne une consigne, une conversation évoque une solution abandonnée. Pourtant, le raisonnement manque. Pourquoi avoir choisi cette option ? Dans quelles conditions était-elle valable ? Une équipe peut conserver ses fichiers et perdre ce qui permettrait de les utiliser. Pour Darkwood, qui relie logiciel, infrastructure, automatisation et IA, cette rupture de contexte est concrète : chaque reprise risque de rouvrir une discussion déjà tranchée.

Une décision doit pouvoir se retrouver et se comprendre. L'identifiant stable lui donne une adresse qui résiste aux changements de titre. La date la situe dans un état du projet. La provenance indique si elle vient d'une contrainte observée, d'un essai ou d'une préférence. L'historique montre ce qui a changé. Ces informations transforment une phrase isolée en connaissance réutilisable. Elles rendent également possible le désaccord : on peut réexaminer un choix sans effacer le chemin qui y a conduit.

L'atelier Darkwood de Memory met ce principe à petite échelle. La recherche de MEM-001 retrouve une décision fictive sur la conservation des motifs musicaux. La première version garde seulement un rendu audio. La suivante conserve aussi les notes, le tempo et les paramètres nécessaires pour créer une variante. Le changement porte sa date et son origine, elles aussi fictives. La lecture des deux versions rend la seconde intelligible : on comprend ce que le choix initial ne permettait pas de reprendre.

Cette distinction compte particulièrement lorsqu'un agent IA participe au travail. Une conversation contient des essais, des hypothèses, des corrections et parfois des instructions devenues inutiles. Tout conserver dans l'historique ne dit pas quels passages font encore autorité. Le contexte transmis à l'agent doit donc désigner les références pertinentes et leur statut. Retrouver un ancien message peut aider ; retrouver une décision validée, reliée à ses raisons et à sa version, fournit une base beaucoup plus précise pour agir.

Une recherche par proximité de sens facilite ce rappel lorsque les mots de la question diffèrent de ceux du document. Elle ne vérifie ni l'actualité de la réponse ni l'autorisation de l'appliquer au problème présent. Un résumé réduit le volume à relire, au risque de retirer une réserve décisive. La mémoire des connaissances demande de garder un accès au détail. Une conclusion courte devient plus utile lorsqu'elle permet de revenir au document dont elle dépend.

Dans l'écosystème, les catalogues de dépôts et de domaines suivent déjà cette logique de repérage. Ils donnent une référence commune pour retrouver un projet ou une destination connue. Leur rôle reste délimité : connaître un domaine n'autorise pas sa création, et retrouver un dépôt ne prouve pas qu'il est disponible sur chaque machine. Cette sobriété me paraît essentielle. Une mémoire fiable exprime autant la portée d'une information que son contenu ; elle évite de transformer une indication pratique en permission générale.

Le partage entre personnes et agents demande la même attention. Une identité commune peut faciliter les accès ; chaque document conserve son public et sa responsabilité. Il faut pouvoir corriger une référence, retirer une donnée et distinguer une proposition d'une instruction adoptée. Une note périmée, chargée automatiquement, peut faire plus de dégâts qu'une note absente. L'oubli devient une opération de maintenance, qui préserve les raisons nécessaires pour comprendre les changements.

La suite envisageable pour Darkwood consiste à rendre ces gestes réguliers : relier une correction à la décision concernée, signaler une connaissance à revoir, charger le contexte utile. Une mémoire universelle ne relie pas pour autant les six services. Des documents lisibles et des références stables peuvent suffire. À la prochaine interruption, une personne doit pouvoir reprendre en comprenant ce qui est établi, ce qui reste ouvert et ce qu'elle peut remettre en question.

Flow — La mémoire de l'exécution

À l'intérieur d'un programme, la question se resserre : de quelles données l'étape suivante a-t-elle besoin ? Un calcul produit une valeur, une transformation l'enrichit, une autre l'utilise. Cette continuité constitue déjà une mémoire, parfois limitée à quelques appels de fonction. Flow intervient ici : la bibliothèque PHP compose des traitements et organise leur exécution. Pour comprendre son apport, commençons par le chemin des données, avant de parler de sauvegarde ou de reprise.

L'exemple réel ajouté à Memory utilise le package darkwood/flow, dans sa version 8.1.6. Trois closures reçoivent successivement un tableau PHP. La première additionne 4, 7 et 9 et ajoute le total, 20, à l'état transmis. La deuxième utilise ce total pour calculer la moyenne. La troisième calcule ce qui reste sur 100, soit 80, puis recueille le résultat. Un compteur confirme que l'addition n'a eu lieu qu'une fois. Les étapes suivantes disposent du travail précédent parce que son résultat accompagne les données.

Dans cet exemple exécutable, FlowFactory assemble les étapes, un objet Ip porte l'entrée, puis await() attend la fin du traitement. Les opérations restent des primitives PHP : un tableau, une addition, une division et des fonctions. Cette courte chaîne pourrait aussi s'écrire sans bibliothèque. Sa taille permet d'observer le contrat de transmission. Flow prend son intérêt lorsque l'organisation de l'exécution justifie cette composition, sans demander de réinventer les calculs.

Le résultat est visible dans la démonstration Flow, avec son code. Le site public étant statique, PHP s'exécute pendant sa génération. Le navigateur reçoit le résultat ; il n'exécute pas la bibliothèque. L'atelier interactif voisin utilise du JavaScript pour faire varier un calcul et observer plusieurs durées de mémoire. L'une des expériences montre le passage d'état réel dans Flow, l'autre rend la différence de durée sensible.

Le premier état est temporaire et disparaît à la fin d'une évaluation. Le deuxième réutilise un résultat au cours du même travail : deux lectures d'une somme partagent un calcul. Le troisième conserve une valeur dans le stockage du navigateur. Elle peut être retrouvée après un rechargement, tant que ce stockage existe. Une variable, une valeur réutilisée et une donnée sauvegardée répondent à trois besoins distincts, même lorsqu'elles contiennent le même nombre.

Dans l'exemple PHP, le total est transporté une fois calculé. Flow ne décide pas pour autant de le conserver pour demain. Chaque nouvelle exécution repart d'un état neuf. Une application qui souhaite garder ce résultat doit choisir son support, sa clé et les conditions de sa réutilisation. Si les nombres d'entrée changent, une ancienne somme n'est plus valable. Si la règle de calcul évolue, il faut aussi savoir quelle règle a produit la valeur conservée. La mémoire durable commence avec ces engagements supplémentaires, au-delà du simple enchaînement des fonctions.

La portée de l'état est également une question de correction. Une ressource réutilisable peut rester disponible entre plusieurs opérations, tandis que les données propres à une opération doivent être isolées. Conserver davantage n'améliore pas automatiquement un traitement : on peut retenir un résultat devenu faux ou laisser une donnée appartenant à une exécution influencer la suivante. Il faut nommer ce qui survit, savoir quand le réinitialiser et pouvoir expliquer pourquoi une valeur a été reprise. Le débogage devient plus clair lorsque cette durée de vie est explicite.

L'évolution intéressante serait de documenter ces frontières dans les traitements consommateurs de Flow : quelles entrées ont circulé, quel résultat garder, quelle opération relancer ? Ce sont des choix d'application. Ils ne constituent pas une reprise durable après panne ou une mémoire partagée d'agents déjà fournie par Flow. La mémoire de l'exécution a une portée précise : transmettre assez d'état pour que le travail avance, puis décider de ce qui doit lui survivre.

Uniflow — La mémoire des processus

Un travail récurrent laisse souvent une méthode dans la tête de la personne qui l'accomplit. Elle connaît l'ordre des opérations, les informations à réunir et les vérifications nécessaires. Lorsqu'elle s'absente, ces évidences deviennent des questions. Formaliser un processus transmet cette manière de faire. C'est le terrain d'Uniflow : représenter des tâches reliées et conserver leur définition pour retrouver, comprendre et réutiliser un enchaînement.

Le projet enregistre des programmes avec leur contenu structuré, leur nom et leur description. Ils peuvent être rattachés à un utilisateur, à un dossier et à des tags ; leur visibilité fait également partie des données conservées. Cette organisation donne une place durable à une méthode de travail. Une définition enregistrée reste toutefois distincte de ce qui arrive lorsqu'on l'exécute. Connaître la recette d'un bilan ne permet pas de savoir si celui de ce matin a été préparé, interrompu ou validé.

La démonstration Uniflow de Memory sépare précisément ces deux plans. D'un côté, une définition nommée « Préparer un bilan » décrit trois étapes : collecter des valeurs, les additionner, produire le bilan. Elle porte un identifiant et une version. De l'autre, chaque lancement crée une exécution distincte. Avec les valeurs 12, 8 et 5, le total obtenu est 25. Le traitement se met en pause après l'addition. Reprendre cette exécution produit ensuite le bilan en utilisant le total déjà disponible.

Le détail important est le curseur : il indique où le travail s'est arrêté. Le résultat intermédiaire permet de poursuivre, tandis que les événements racontent les étapes accomplies. Une deuxième demande de reprise ne recommence pas le bilan terminé. L'expérience reste entièrement locale au navigateur et ne déclenche aucun moteur Uniflow de production. Elle rend visible un contrat de reprise que l'on peut examiner séparément de l'interface : quelle opération reste à faire, avec quelles données et sur quelle exécution ?

Une trace écrite ne constitue donc pas, à elle seule, un point de reprise. « Addition terminée » est une information utile pour comprendre un déroulement. Pour continuer réellement, il faut encore disposer du total et savoir quelle définition l'a produit. Si la méthode change entre l'arrêt et la reprise, la question devient plus délicate : faut-il poursuivre selon l'ancienne règle ou lancer un nouveau traitement ? Le numéro de version de la démonstration permet de poser le problème. Il ne prétend pas le résoudre pour toutes les situations.

Cette distinction devient cruciale dès qu'un processus agit au-delà de son propre calcul. Imaginons une tâche qui prépare un message, attend une validation puis l'envoie. Refaire la préparation peut être sans conséquence ; répéter l'envoi engage une autre personne. Une reprise doit reconnaître les effets déjà produits. Cet exemple est une possibilité d'automatisation, sans annoncer une intégration particulière dans Uniflow. Il montre pourquoi la mémoire d'un processus doit séparer proposition, décision et action effectivement réalisée.

La répétabilité comporte une part humaine. Une méthode peut conserver la raison d'une étape et les conditions d'un arrêt. Ces indications aident à modifier le processus lorsque le besoin évolue. Des événements compréhensibles, reliés à la bonne exécution, peuvent être plus utiles qu'un historique exhaustif. Les données sensibles demandent aussi un périmètre clair : rendre une définition partageable ne rend pas publiques les données qu'une personne lui confie.

Pour Uniflow, une piste serait de rapprocher la méthode enregistrée, ses versions et les traces nécessaires à sa reprise, selon les usages. Le point de départ existe dans les programmes structurés du projet ; l'historique et la reprise montrés dans Memory restent une expérimentation pédagogique distincte. La continuité recherchée est celle d'un travail que l'on peut confier, interrompre et retrouver sans devoir deviner ce qui a déjà eu lieu.

Darkwaar — La mémoire du joueur

Dans un jeu, recommencer peut laisser un avantage précieux : une meilleure compréhension. Un passage dangereux devient reconnaissable, une règle cesse de surprendre, un détour prend un sens. Le personnage revient au départ, tandis que la personne devant l'écran a changé. Darkwaar explore cette différence avec Aftertrace, un jeu consacré à la mémoire. Son idée tient dans le trajet entre deux tentatives : ce que l'on découvre doit éclairer le prochain choix.

Aftertrace propose trois petites rives organisées en grilles de quatre cases sur quatre. Le terrain est en partie caché. On avance vers une case voisine avec un clic ou un tap ; certaines cases sont sûres, d'autres se fissurent et interrompent la tentative. Le nombre de pas est limité. Il faut trouver un signal en forme de diamant puis atteindre la sortie. Chercher le chemin demande donc de gérer à la fois l'incertitude et la distance : se diriger immédiatement vers la sortie peut laisser de côté l'information nécessaire pour la franchir.

La première traversée s'effectue les mains vides, pour reconnaître la rive. Quand une fissure arrête la progression, Rewind restaure la position de départ et les pas disponibles en gardant les découvertes sur la carte. Une case dangereuse reste marquée ; une case sûre déjà visitée reste connue. Le jeu donne une forme visible au souvenir. Le joueur peut relire ce qu'il a appris et préparer une route sans devoir retenir mentalement chaque essai.

Atteindre la sortie une première fois ne suffit pas. Après la reconnaissance, Carry ramène au départ avec une braise à transporter. Il faut refaire le trajet en s'appuyant sur la carte acquise. Cette seconde traversée donne sa valeur à la première : découvrir une route devient la condition d'un voyage accompli avec une intention nouvelle. La mémoire influence directement les décisions, puisqu'elle indique les cases à éviter et celles sur lesquelles compter. Le jeu demande d'exploiter une connaissance, au-delà de la simple révélation d'un décor.

La progression change ensuite de rive et efface cette carte. Les trois traversées de reconnaissance ne se confondent donc pas en un savoir illimité. Chaque lieu exige sa propre lecture, et certains chemins reviennent sur leurs pas pour atteindre le signal. On peut également choisir Forget pour effacer les découvertes de la rive courante. La portée du souvenir devient une règle compréhensible : il survit aux retours d'une même exploration, puis cède la place au problème suivant. Recharger le jeu fait également perdre cette mémoire de partie.

Cette limite distingue plusieurs expériences. La carte est une information explicitement conservée par le jeu. Le joueur peut aussi apprendre à regarder les embranchements, à surveiller son budget de pas ou à préparer le retour avant de prendre la braise. Ces habitudes peuvent lui rester après avoir fermé la page. Elles ne sont inscrites dans aucune sauvegarde. Aftertrace réunit ainsi le souvenir représenté à l'écran et l'apprentissage personnel : le premier rend le terrain lisible, le second améliore la manière de l'aborder.

La section Darkwaar de Memory conserve aussi sa chambre à inscription et à carnet, qui montre ce qui reste après une remise à zéro. Aftertrace, jouable dans la même section, prolonge la question par des choix spatiaux, des échecs et des trajets accomplis. Son teaser montre le jeu réel. La brièveté des rives permet de revenir sur une erreur et d'observer ce qu'elle apporte à la tentative suivante.

D'autres jeux Darkwaar pourraient explorer un souvenir incomplet ou une information à transmettre. Ce sont des possibilités de création, pas des fonctions annoncées pour Aftertrace. Elles posent une exigence : le joueur doit comprendre ce qu'il garde et pouvoir s'en servir. Si le souvenir n'influence aucune décision, la répétition devient une attente. Ici, la braise confiée au second départ donne au passé une fonction précise : rendre possible un trajet que l'on sait enfin préparer.

DJMatyo — La mémoire musicale

Une musique peut préparer son propre souvenir. Un motif revient, une pulsation s'installe, une mélodie laisse attendre la note suivante. À la réécoute, la surprise devient un repère ; une variation permet de mesurer l'écart. L'identité Happy Hardcore de DJMatyo donne à cette relation une place particulière. L'énergie rythmique et les lignes mélodiques peuvent porter une impression de familiarité et un désir de mouvement. La répétition entretient l'élan en donnant une forme reconnaissable à ce que l'on entend.

Cette mémoire appartient d'abord à l'écoute. On reconnaît un retour avant de pouvoir le décrire, on attend une reprise, on remarque qu'un silence a déplacé l'accent. Pour le DJ, le choix d'un enchaînement joue avec ces attentes : ce qui précède donne une couleur à ce qui arrive. Une transition peut prolonger une énergie, ménager un contraste ou faire réapparaître une idée. Le fil d'un set tient à ces relations dans le temps. Une succession de morceaux ne conserve pas automatiquement la raison pour laquelle ils se répondent.

La démonstration DJMatyo de Memory réduit cette question à huit pas. Des notes et des silences composent une boucle ; le tempo peut être modifié, le motif écouté puis conservé. Les sons sont synthétisés dans le navigateur, sans sample tiers. Ce matériau original d'atelier ne reproduit aucun morceau de DJMatyo. Il rend le souvenir modifiable : on retrouve une suite de notes dont on peut changer l'organisation.

Le bouton de variation décale la séquence d'un pas. Le vocabulaire reste le même ; la place des événements change. Le retour de la boucle n'a plus le même appui. Cette opération permet d'écouter ce qu'une idée conserve lorsqu'on la transforme : les hauteurs, les silences et certains intervalles restent disponibles, tandis que leur rapport au commencement se déplace. La structure mémorisée donne une origine à la variante sans décider si celle-ci est musicalement préférable.

La conservation porte sur les notes et le tempo. Ils peuvent être rappelés depuis le stockage local ou exportés dans un fichier JSON. Ce fichier décrit de quoi rejouer le motif ; il ne contient pas un enregistrement audio. La différence rejoint un besoin courant de création : garder un rendu permet de réécouter un résultat, garder sa structure permet de le retravailler. À l'échelle d'un projet musical plus riche, il faudrait également retrouver les sons, les paramètres et les ressources dont dépend cette structure. Huit pas suffisent ici à montrer pourquoi les deux formes de mémoire se complètent.

Une identité sonore se construit aussi dans la manière de choisir, de doser l'énergie et de faire revenir des couleurs familières. Pour DJMatyo, la référence Happy Hardcore oriente cette recherche sans imposer de refaire le même enchaînement. Conserver un motif aide à entendre ce qui le rend reconnaissable, puis à essayer ce qui peut changer. Le souvenir laisse au geste présent le choix de prolonger, déplacer ou abandonner l'idée.

La mémoire d'une diffusion a une autre forme. Le projet de streaming DJ organise un cadre de présentation avec logo, habillage et scènes avant le direct et pendant le mix. Ces repères visuels aident à retrouver un cadre d'écoute ; ils ne décrivent pas la fabrication musicale ni l'archivage des sessions. Une piste serait d'accompagner un set de sa sélection et de notes sur ses transitions, lorsque les droits et le contexte le permettent. Une intention se retrouve plus facilement lorsqu'elle est nommée.

Ce que l'on garde doit laisser une possibilité de reprise. Retrouver une boucle permet de l'écouter autrement ; retrouver les raisons d'une transition peut éclairer le prochain set. Entre le souvenir de l'auditeur et les ressources du créateur, la mémoire entretient une relation vivante. Un motif revient, mais la personne qui le fait revenir a quelque chose de nouveau à lui demander. La continuité musicale se joue aussi dans cette distance entre l'idée conservée et l'envie présente.

Heroclip — La mémoire des images et des récits

Le plan suivant hérite de ce que le précédent a rendu important. Un personnage a pris un objet ou quitté un lieu ; la suite doit en tenir compte pour rester lisible. Dans une création vidéo générative, cet héritage demande à être formulé. Une image réussie ne transmet pas toutes les intentions qui l'ont produite. Heroclip, conçu autour de récits vidéo courts poursuivis par la conversation, rencontre cette difficulté au passage d'un segment à un autre.

Le projet conserve un brief initial et les générations qui lui sont rattachées. Une génération peut garder sa variante choisie, son storyboard, le texte de génération vidéo, son résultat et un lien vers sa génération parente. Cette filiation rend le chemin de création repérable. Elle indique à quel état du récit répond une proposition et permet de distinguer le point de départ d'une continuation, sans imposer que toutes les générations soient identiques.

Un mécanisme de mémoire est déjà présent dans le code d'Heroclip. En mode continuation, il sélectionne jusqu'à trois storyboards issus de générations réussies et les transmet au travail de préparation du suivant. Certains champs textuels sont raccourcis pour borner leur longueur. Le contexte est donc choisi et limité : l'intégralité du passé ne revient pas à chaque demande. Une dernière image peut également servir de référence lorsqu'elle est disponible, selon la configuration utilisée. Cette possibilité ne doit pas être confondue avec une continuité visuelle garantie.

La sélection pose une question artistique autant que technique. Un accessoire décisif peut avoir été introduit avant les segments retenus. Une description raccourcie peut perdre une nuance de geste ou de lumière. Trop de détails peuvent aussi masquer l'intention principale. Le choix du contexte engage ce que l'on veut préserver : le personnage, l'action accomplie et la direction du récit ne demandent pas nécessairement le même niveau de détail que la décoration d'un arrière-plan.

La démonstration Heroclip de Memory rend ce passage visible sans générer de vidéo. On choisit un personnage et une palette ; des règles locales construisent une suite de plans. Avec le rappel activé, le plan suivant conserve le personnage, la couleur et l'accessoire précédents. Sans rappel, il reprend des valeurs par défaut. Ce storyboard déterministe, limité à six plans, illustre la transmission des repères. Il permet de comparer ce que reçoit la suite quand on lui transmet le passé et quand on l'omet.

Dans une vidéo, le contrôle va plus loin. Conserver le nom d'un personnage n'assure ni le même visage ni les mêmes vêtements. Une palette commune ne garantit pas le raccord de lumière. Les repères orientent la production ; le visionnage établit si le résultat convient. Une génération techniquement réussie peut demander une correction artistique. Garder cette distinction évite de propager une incohérence simplement parce qu'elle a déjà été produite.

La durée de vie des médias pose un problème voisin. Une référence vers une vidéo permet de la retrouver tant que sa destination reste disponible. Elle n'équivaut pas à une archive maîtrisée. Reprendre une histoire peut demander de garder le média, les choix de storyboard et les paramètres de sa sélection. La filiation conservée dans le projet constitue un appui ; une politique de conservation complète reste à définir selon les usages, les droits et les coûts de stockage.

Une évolution possible serait de rendre plus explicites les invariants d'une histoire : ce qui doit rester reconnaissable, ce qui peut évoluer et ce qui vient d'être corrigé. Une fiche de continuité pourrait compléter les storyboards récents sans prétendre résumer toute l'œuvre. L'enjeu serait de rendre ces repères révisables par la personne qui crée. La mémoire narrative prend alors une direction précise : donner au prochain plan des engagements compréhensibles, tout en laissant la place à un événement nouveau. Une histoire continue parce qu'elle se souvient aussi de ce qu'elle n'a pas encore raconté.

Conclusion

Une décision garde ses raisons, un calcul transmet un résultat, un processus conserve sa méthode. Le joueur apprend un chemin, le musicien retrouve un motif et le récit emporte ses repères vers une nouvelle scène. Leurs supports et leurs durées diffèrent. Leur cohérence vient de l'attention portée à ce qui reste utilisable. Pour Darkwood, cela conduit à des choix concrets : rendre une origine lisible, délimiter un état, permettre une correction ou un effacement. Chaque activité demande de décider ce qu'elle mérite de garder. La suite devient possible lorsque ce choix donne assez de prise pour reprendre, comprendre et transformer.