En Septembre 2026 je retourne en 2008 avec... eMule ?

Mais où revoir Keroro ?

Bon, il doit bien exister un site qui le diffuse en VF, histoire que je puisse revoir cette série dont j’ai si bon souvenir ? Non, personne. Aucun site de streaming, aucun revendeur de DVD ou Blu-Ray ne diffuse la version française de Keroro. Presque personne n’en parle en ligne, mis à part un ou deux post reddit aussi perplexes que moi.

J’en suis même venu à douter de mes souvenirs, et si ce n’est pour ce générique qui reste gravé dans mes souvenirs j’aurais cru avoir imaginé une version française.

kero kero kero, en avant les amis~

En Juin je quitte en bons termes mon job d’ingénieur API chez Pictarine, avant de trouver un nouveau travail à Bordeaux, j’ai du temps libre. J’ai donc mis ce temps à profit : Je veux retrouver le doublage français de Keroro Mission Titar !

L’histoire de la VF de Keroro Mission Titar

Quand on se penche sur la production de Keroro en France, on comprend assez vite pourquoi c’est un media perdu aujourd’hui.

Parler d’une seule VF est même encore un abus de langage, car il y a en réalité deux studios qui se sont succédés pour doubler les aventures de la troupe de grenouilles. Les 13 premiers épisodes ont été doublés par les français de Mediadub International, puis redoublés par Made In Europe et Agent Double, des studios belges qui eux sont chargés de doubler les 103 épisodes des saisons 1 et 2. Les épisodes ont été diffusés sur Télétoon et IDF1, mais il n’y a eu acune sortie physique. Impossible de se procurer une copie légitime même d’occasion.

Bon, et qui convaincre de rediffuser Keroro ?
C’était Rouge Citron qui a acheté les droits de diffusion en France à Sunrise et ses partenaires, puis a commandé le doublage à Mediadub International… Sauf que Rouge Citron a déposé le bilan en 2007 et les droits d’exploitation de Keroro ont été repris par Media Participations (le groupe détenant ADN et Kana) qui a commandé le doublage belge.
Il faut aussi noter que les droits initiaux achetés à Sunrise avaient possiblement aussi une date d’expiration, donc convaincre Media Participations de rediffuser la série via ADN ou Kana Home Video ne serait pas forcément suffisant non plus…

📝 Note
Ceci est mon avis personnel, et ne saurait engager quelque autre structure dont je serais représentant direct ou indirect.
Le partage non autorisé d’œuvres soumises au droit d’auteur est illégal en France, y compris dans les situations où les ayant-droits ne diffusent pas les œuvres en question.

Je ne développerai pas aujourd’hui mon avis complet sur le système de droits d’auteur moderne en France où ailleurs.
Disons juste que je ne pleurerais pas une entreprise ayant les droits d’exploitation sur un trésor de mon enfance choisissant de ne pas les exercer, “flouée” par la résurrection d’une oeuvre qui a fait tant rire l’enfant que j’étais.

Keroro Mission VF

Le 3 juin 2026, je rejoins sur Discord un groupe de passionnés qui donne tout pour essayer de retrouver ce lost media : Lost Media Keroro Mission VF. J’épluche tous les salons, je me renseigne sur tout ce qui a pu être essayé, toutes les pistes sans issue, toutes les personnes qui ont bossé sur cette VF et ont été contactées par les fans. La communauté a remué ciel et terre pour le sergent grenouille.

Et ces efforts ne sont pas vains : certains épisodes ont été retrouvés et partagés sur la chaîne youtube Keroro VF Archives. Alors il y a de l’espoir, ces épisodes existent bien quelque part, il suffit de les trouver.

Il ne faudra pas attendre longtemps. Le 7 juin, une annonce générale est faite par une modératrice : On vient de retrouver l’épisode 62 sur eMule.

@everyone bonjour à tous !
Grande nouvelle : un nouvel épisode a été retrouvé sur eMule !
Il s’agit de l’épisode 62 !
On croise les doigts pour en trouver davantage !
En attendant : bon visionnage à tous ! ⭐
Ps : le nom original du fichier était [TV] KERORO MISSION TITAR N°062A « Les demoiselles cambrioleuses » [Dimanche 21 septembre 2008 à 16H50 sur TELETOON].avi si jamais ça peut aider ~

Je veux aider, et si une chose est sûre, c’est qu’il faut scruter eMule plus attentivement.
Soyons clairs, ed2k et Kademlia, en 2026 c’est pas les technologies hype du moment, c’est plus des choses dont j’entendait mes parents et leurs amis discuter quand j’étais gamin. L’outillage existant est assez sommaire, et pas franchement foisonnant. Un OVNI nommé aMule plane quand même sur l’écosystème, et tant mieux : heureusement qu’un fork moderne d’eMule existe.

Armé de mon client, je lance une recherche par ci par là, sans grand succès.
Je dois m’y résigner, si je veux faire les choses bien il me faut un crawler qui tourne 24h/24.

Création d’un crawler pour ed2k/kad

Le 10 juin je me lance, pas question de rater des nouveaux épisodes.
Tout ce qui pourrait correspondre à une piste doit être consigné quelque part, et si c’est assez prometteur, je dois impérativement être notifié et le fichier doit être automatiquement téléchargé.
Je me lance dans une aventure de plus d’un mois, à un rythme assez inégal.
Assisté par un Claude Opus acting as développeur, je mets ma plus belle casquette d’architecte, objectif avoir un crawler eMule qui ne rate rien et est assez malin pour trier le grain de l’ivraie.

Le principe de Mulewatch est une boucle : chercher -> trier -> cataloguer -> agir.
Pour faire ce filtrage efficacement, je commence par sélectionner des mots clés de recherche emule, puis à partir d’eux je construis des filtres négatifs pour exclure les fichiers qui sans l’ombre d’un doute ne sont pas Keroro Mission Titar en VF. Au final, contrairement à ce que je pensais, il y a assez peu de faux positifs absurdes, avec keroro et titar comme mots clés, je n’ai quasiment que des contenus pertinents, à l’exception de quelques bizarreries.

Bon, c’est sans noter que les communautés non-francophones sont majoritaires. Alors chirurgicalement je dois trouver des caractères UTF-8, des conventions de nommage, ou des mots qui permettent de ne garder que la VF sans trop de zèle pour autant, il serait catastrophique d’exclure un épisode francophone par erreur.

J’arrive dans des cas limites, puisque c’est toujours ce qu’il se passe quand on confronte un programme à un flux de données pointé sur Internet. Est-ce qu’on doit garder keroro.avi ? Et keroro.zip ? C’est pas explicitement de la VF, mais ça pourrait en être, impossible d’être sûr d’office, on ne peut pas l’exclure sans l’avoir vérifié en inspectant le contenu. Il faut plus granulaire que in/out, on doit attribuer un score à un fichier à partir de son nom. Mais qu’est-ce qui fait qu’un fichier est plus prometteur qu’un autre ? On a déjà eu un indice quand on a trouvé le 62A, avec un nommage particulièrement consciencieux :

[TV] KERORO MISSION TITAR N°062A « Les demoiselles cambrioleuses » [Dimanche 21 septembre 2008 à 16H50 sur TELETOON].avi

Plusieurs choses vous font possiblement tiquer, mais partons des mots clés keroro et titar, qui trouveraient déjà ce fichier.
Déjà, la chaine de mots complète “Keroro Mission Titar”, c’est le nom francophone. Télétoon, c’est bien une chaine sur laquelle l’anime a été diffusé. Dimanche 21 Septembre 2008, c’est bien dans la période de diffusion attendue.
Mais on pourrait aussi bien avoir un fan qui redistribue juste des fichiers adjacents, comme des revues de presse, des screenshots, des pubs, des assets… Bref, des choses qui nous intéressent mais pas le trésor.
Ce genre d’indices indiquant qu’on est bien face à du contenu Keroro francophone formeront le tier notify, qui peut comme le nom l’indique me notifier par n’importe quelle méthode supportée par Apprise.

Non, ce qui fait foi ici, c’est surtout .avi, 062A et Les demoiselles cambrioleuses, si on se base sur la liste des épisodes de Keroro Mission Titar, ça correspond parfaitement à un épisode, il n’y a aucun doute possible sur ce nom de fichier. Alors, je mets tous ces épisodes cibles dans un fichier de données, et tout fichier dont le texte se rapproche d’un nom d’épisode est accepté en tier download.
Alors oui, on pourrait avoir affaire à un petit malin qui envoie une vidéo toute autre avec ce nom de fichier, mais rassurez vous, la quantité de trouvailles à trier à la main n’est pas vraiment gargantuesque.

Initialement je prévois très vaste, et en v1.0 Mulewatch est un Docker Compose complexe.
Un crawler, un vérifieur clamav, aMule, gluetun, prometheus et grafana.

Schéma d’architecture de Mulewatch lors de son annonce

Je vous l’accorde, c’est très overkill pour un crawler, mais je me suis dit autant faire les choses bien dès le début.
Les métriques Prometheus custom avec un dashboard Grafana, ça aurait pu aider à diagnostiquer les problèmes en comportement réel déployé. Le vérificateur avec ffmpeg et ClamAV, plus le conteneur Freshclam pour mettre à jour les définitions de fichiers dangereux, ça aurait évité de conserver des fichiers dangereux ou… douteux. Triste réputation que s’était forgé eMule, à tort ou à raison.

Sauf que dans les faits, on a des logs, et on a déjà le moteur de matching dans le crawler pour raffiner ce qui est retenu ou non. Je déciderai plus tard d’élaguer Mulewatch pour le rendre plus simple à maintenir, débugger et déployer.

Le 5 juillet, j’ai la confirmation que le bot Mulewatch fonctionne comme prévu, car il retrouve l’épisode 62A indépendamment. C’est encourageant, et j’ai un regain d’énergie. Il faut publier ce bot et le laisser tourner ! J’améliore le matcher, je nettoie un peu le code, et le 20 j’envoie un message dans le discord communautaire pour annoncer Mulewatch.

Je le laisse tourner, mais rapidement, en l’absence de nouveau contenu intéressant, je l’oublie un peu.

Premier ping sur le radar

Fidèlement, le reste de Juillet, tout Août, Mulewatch veille au grain.
Mais rien de rien. C’était peut-être une source secondaire, et il n’y aurait rien sur eMule en fin de compte ? Evidemment, ç’aurait été une grave erreur de stopper mon usine à gaz sur ce préjugé.

Le 11 Septembre, je décide d’aller jeter un oeil au catalogue de Mulewatch après plus de 2 semaines à l’avoir laissé tourner dans son coin.

Mulewatch a catalogué 8 nouveaux épisodes, aperçus depuis le 1er Septembre.
Il a vu 65A, 65B, 66A, 67B, 68A, 68B, 69A, 69B.
Et aucun n’a été téléchargé. Pas parce que le fichier n’a pas été reconnu, non, parce que mon connecteur aMule avait un bug. C’est la tuile…

J’alerte la communauté, et une équipe “Keroro Mission eMule” se forme.
Rapidement, on se rend compte que le 62A était bien un cas isolé, sa source “MiaoussMalicieux” ne semble pas avoir d’autres épisodes complets de Keroro Mission Titar.

Chaque jour, un nouvel épisode est détecté à 00:01, partagé par une source mystérieuse nommée “AnimuseeFMR”.
Iel limite ses envois à 1Ko/s, débit scindé en 2 slots de téléchargement.
Autre difficulté : AnimuseeFMR a ce qui s’appelle un “low id”. C’est à dire qu’il faut qu’on ait soi-même un port ouvert sur son routeur pour communiquer et obtenir des données, et qu’il faut être connecté au même serveur ed2k pour que la négociation nécessaire au téléchargement s’amorce.

Non, vous n’avez pas mal lu, et ce n’est pas une coquille, je dis bien 1Ko/s.
Donc en théorie, on a une limite maximale de 86.4Mo (82.3Mio) téléchargeables en 24h.
C’est important comme seuil, car tous les jours, religieusement, AnimuseeFMR stoppe le partage du fichier courant, et passe au suivant. Un épisode plus gros que la limite ne passera pas dans la journée, c’est physiquement impossible.

Les épisodes 70A à 76A s’enchaînent, tous trop longs pour rentrer en une journée complète de télechargement sans pertes. On essaie chaque jour d’obtenir 50% de téléchargement, en espérant qu’un jour la source rebouclera et on pourrait alors compléter nos téléchargements partiels…

Interlude : Dé-usine-à-gaz-er Mulewatch

Bon, c’est bien beau de cataloguer des épisodes, mais il s’agirait de les télécharger.
Le fix du téléchargement en lui même est un patch banal, mais si on peut faire en sorte que le schéma d’architecture de Mulewatch ressemble moins à un sac de nœuds au passage, ça serait pas mal aussi.

Commençons par “Do one thing, and do it well”.
Un bot à la recherche de lost media n’a pas besoin d’un antivirus ni d’un dashboard d’observabilité complet.

Le nombre de fichiers trouvés est faible par définition, il est acceptable de déléguer la vérification des fichiers téléchargés à l’opérateur. Pour le débogage et la surveillance opérationnelle on a les logs, pas besoin de suggérer par défaut Prometheus et Grafana, c’est plus un usage pour les nerds d’observabilité (-> comprendre mélioratif) que pour un chercheur de lost media.

Le 13 Septembre, je fais ces deux coupes et on y voit déjà plus clair :

Schéma d’architecture de Mulewatch v2.0.0

Pourquoi on a besoin d’un conteneur docker-proxy d’ailleurs ?

Pour avoir un high id et découvrir un maximum de sources ed2k/kad, il faut être joignable par un port exposé à internet. L’alternative est d’avoir un low id, et ne pas pouvoir contacter d’autres clients low id. Pas idéal pour un crawler.

Si on expose un port directement dans la section NAT de son routeur, c’est assez simple.
Mais si on utilise un VPN commercial à travers Gluetun, on ne peut pas prévoir quel port va nous être ouvert chez le fournisseur, puis être annoncé par Gluetun, donc il faut qu’on l’interroge régulièrement puis qu’applique le port dans les réglages d’amuled.
Sauf qu’amuled ne supporte pas le changement de port à chaud, il faut redémarrer son conteneur pour appliquer le changement.

Par principe je ne suis pas fan de permettre à mon crawler maison de redémarrer n’importe quel conteneur en lui donnant directement accès au socket docker, donc je n’expose que le redémarrage de container_name: amuled via un proxy prévu à ce sujet.
Ça évite les bêtises honnêtes de programmation mais aussi l’impact des bourdes de LLMs, et ça réduit un peu la surface d’attaque si le crawler venait à être compromis et permettait l’exécution de code à distance (RCE).

Sauf que rien ne dit qu’on doit absolument avoir deux conteneurs différents !
Or, si les deux processus sont frères, on peut utiliser un système comme s6-svc pour les orchestrer proprement et redémarrer amuled quand on en a besoin depuis le crawler.

Il faut un peu filouter parce que les dépôt de debian ne distribuent pas une version d’aMule assez récente. Pour contourner le problème, et pour éviter de recompiler aMule (foreshadowing) je décide de l’embarquer comme paquet nix, installable sans trop de problème sur Debian.

Oui, je sais : “Sacrilège, un conteneur = une app”.
Mais une app, c’est un concept arbitraire, rien ne dit que l’on doit absolument avoir un process par conteneur. Si on découplait les conteneurs crawler et client de recherche / téléchargement, on devrait continuer de payer le prix fort avec une architecture pas franchement adaptée et plus compliquée que nécessaire. Donc pour la v2.0 on embarque amuled dans le conteneur du crawler avec nix, et on orchestre le tout avec s6.

Schéma d’architecture de Mulewatch intermédiaire

Ok, pas mal, on y est presque.
Bon, par contre c’est quoi ces communications vers amuled marquées “EC” ?

Pour piloter le process amuled depuis l’extérieur il n’y avait qu’un choix, et c’est parler “Externam Connections”, EC pour les intimes, un protocole binaire passant par un socket TCP. Rien d’insurmontable, surtout quand on travaille avec une app open-source, mais pas très pratique.

Avec aMule 3.1.0, amuleapi a été introduit. Il d’agit à la fois d’une nouvelle interface web qui remplace l’interface web datée et incomplète amuleweb, mais aussi d’une API REST pour piloter amuled. On pourrait se dire que dans un projet qui dépend tant de son client ed2k/kad, ce serait une réécriture douloureuse et source d’erreurs, et ce serait le cas si je n’avais pas pensé le crawler pour suivre strictement la Clean Architecture de Bob Martin.

Apparté Architecture logicielle

C’est vrai, c’est plus verbeux d’écrire domaine, ports, adapteurs. Mais quand on en a besoin, bon sang que c’est satisfaisant de virer un adapteur pour un autre et être confiant que l’on a pas d’effets de bords grâce à un design bien pensé ! Et à l’époque des agents, il serait inconscient de ne pas s’acheter de la sérénité par design quand on sait qu’un Claude abattra ce travail supplémentaire de découplage sans même qu’on puisse le remarquer dans le budget temps.

Je crois que l’on est dans une ère où l’architecture logicielle et le system design sont peuvent dicter la vie ou l’étouffement par la dette technique immédiate d’un projet logiciel. Tout va plus vite, la marge que l’on pouvait avoir pour prendre des raccourcis dans le code avant de payer le prix des défauts d’architecture se réduit de façon proportionnelle à la vitesse des coding agents.

Apparté fini, il va falloir embarquer aMule 3.1.0 pour profiter de cette super API et Web UI.
Il faut qu’on parle distribution logicielle, parce que depuis mulewatch v2.0 on amène déjà aMule depuis une source différente du reste des paquets. Ce ne serait pas forcément un problème en soit si le dépot nixpkgs était supervisé par des personnes expertes et de confiance, or n’importe qui peut approuver une PR pour changer un paquet.
Quelle horreur !

Il n’est pas cohérent de d’un côté se baser sur Debian pour la stabilité et la réputation de sérieux, et de l’autre embarquer un paquet qui peut être modifié à tout moment par n’importe qui.

Si j’avais mieux creusé pour en savoir plus sur nixpkgs, je ne l’aurais pas utilisé pour une app déployée, d’autant plus que je fais attention à la sécurité de la chaine d’approvisionnement sur Mulewatch : Image docker signée, SBOM déclaré, scan de CVEs journalier et VEX pour exclure les faux positifs. Définitivement on ne peut pas garder une dépendance à nixpkgs, si on veut embarquer aMule 3.1.0 il va falloir en installer les dépendances et le compiler nous même.

Schéma d’architecture de Mulewatch v3.0.0

L’architecture de Mulewatch est maintenant dans un état acceptable, et on peut retourner à la recherche.

Premier fichier complet

C’est le 28 Septembre à 00:02 qu’on a vu l’épisode 76B apparaitre dans les résultats de recherche.
Le moins qu’on puisse dire, c’est qu’on avait espoir. En réalité, on était fous de joie !

Conversation Discord surexcitée entre Willex et DL21 à propos de l’épisode 76B

Et on avait raison d’y croire, car à 18h48 DL21 avait le fichier complet.
C’est dans une euphorie générale que nous avons retrouvé l’épisode [TV] KERORO MISSION TITAR N°076B « Emmène-moi sur la lune 2 » [Dimanche 05 octobre 2008 à 11H10 sur TELETOON].avi 🎉

Aujourd’hui, le demi-épisode est sauvegardé

Chez plusieurs chercheurs de lost media,
Sur le réseau ed2k/kad,
Sur archive.org,
Dans la DHT de bittorrent,
Sur YouTube (bientôt),

Fun fact : La DHT de bittorrent est basée sur Kademlia, le protocole également utilisé par eMule. Le kad de ed2k/kad signifie Kademlia ! Pour autant, les deux réseaux sont incompatibles entre eux, il ne font que partager un protocole de base.

Fusionner des données ed2k incomplètes entre pairs

Si jamais vous l’avez oublié, le protocole ed2k n’est pas tout jeune, venant d’une époque ou le débit résidentiel haut de gamme était de quelques Ko/s. Il n’est pas aussi permissif que bittorrent dans son découpage de fichiers, une partie n’est rediffusable aux autres clients que quand un bloc de données de ~9Mo est complet. Avant ça, on a des données, mais impossible de les redistribuer à ses pairs.

Ce découpage grossier joue en notre défaveur quand on travaille avec de faibles débits d’upload, puisque rien ne garantit que l’on pourra télécharger toute une partie et qu’on pourra donc la redistribuer à notre tour. Dans le pire scénario, tous les clients peuvent tour à tour obtenir une même partie #N et la compléter à 99% depuis une source lente, et la quantité de données uniques obtenues est minimale. Dans un monde idéal, chaque client pourrait repartager ce qu’il a reçu et il n’y aurait pas d’envoi dupliqués de données, mais on ne peut pas agir sur le design d’un protocole déjà désuet depuis 20 ans, on doit faire avec.

Mais les fichiers .met et .part d’aMule n’ont rien de sorcier, et il est tout à fait possible de combiner les téléchargements incomplets de deux pairs pour en faire un téléchargement plus complet, union des octets.
DL21 a émis cette hypothèse et quelques heures plus tard, elle partage un script preuve de concept pour fusionner des téléchargements incomplets. Quelques heures encore après, j’ai converti le script en webapp sans serveur, tournant entièrement dans le navigateur pour faire cette fusion en lot.

Code source : https://github.com/mission-titar/amule-part-merger
Web App : https://mission-titar.github.io/amule-part-merger/

Screenshot d’amule-part-merger montrant la reconstitution de l’épisode 76A

Dans cet exemple, le résultat est flagrant, le fichier vidéo résultant de la fusion de 3 pairs gagne 27.7% par rapport aux parties communes partageables par ed2k. Trois des clients avaient obtenu chacun une partie presque complète, et ces données n’ont pas pu être partagées par ed2k, on les met en commun par l’outil.

L’avantage en dehors d’une optimisation de la bande passante de la source quand le fichier est de nouveau partagé, c’est que l’on peut visionner le fichier vidéo largement sans encombres dans VLC, et que les données manquantes sont un peu de l’intrigue pré-générique. On peut visionner les deux parties de l’épisode 76 (quasiment) en entier, grâce à une astuce pour surmonter les faiblesses du protocole ed2k.

Conclusion

Aujourd’hui, on est encore à l’affut, dans l’objectif de retrouver tous les épisodes de Keroro Mission Titar. La recherche de lost media, c’était un coin d’internet que je ne connaissais pas vraiment avant, et j’y ai trouvé des gens d’une motivation et d’une persévérence sans faille. C’est une expérience très plaisante, et je suis un peu sonné d’avoir pu apporter une contribution fructueuse et des outils à la communauté de chercheurs de Keroro en VF.

C’est un peu cheesy, mais au final ce qui nous a permis de réussir est la persévérence.
Merci à DL21, Gaoura, Kanari Raspberry, UniversJB, et tous les autres membres de la communauté qui ont soutenu la petite équipe de soldats d’eMule.

Si nos estimations sont justes, on pourrait possiblement obtenir tous les épisodes de la VF d’ici un an, en supposant que la source reboucle sur les épisodes précédents. Pour autant, on compte bien continuer de se creuser les méninges et retourner tout internet pour trouver ces épisodes.