Démêle — l'histoire du projet

Colle le chaos, récupère le plan.

Le problème

Tout le monde a déjà vécu cette conversation de groupe : cinquante messages, des « ok pour moi », des « on verra », trois sujets mélangés, et à la fin, personne ne sait vraiment qui fait quoi.

Un résumé automatique ne règle pas ça. Pire, il l'aggrave : il lisse les zones floues et donne l'impression que tout est décidé. Dans un travail de groupe, c'est ce flou-là qui fait rater les échéances.

L'idée

Démêle est une application web où l'on colle une conversation de groupe (WhatsApp, Slack) ou des notes de réunion. Elle renvoie un plan en trois colonnes :

Colonne Contenu
Décisions Ce qui a été tranché, et par qui c'est confirmé.
Tâches Ce qui reste à faire, avec un responsable et une échéance.
Points à clarifier Ce qui est resté flou : pas de responsable, décision non tranchée, contradiction, échéance manquante.

La troisième colonne est le cœur du produit. Démêle ne cherche pas à tout résumer : il trie, et il montre ce qui n'est pas réglé.

La règle qui définit le produit

L'IA ne devine jamais un responsable.

Si personne ne s'est clairement engagé, l'élément ne devient pas une tâche : il va dans « Points à clarifier ». Un exemple tiré de mes données de test : quand quelqu'un écrit « Je peux m'en charger si personne d'autre ne le fait », c'est un engagement conditionnel. Démêle ne le transforme pas en tâche.

Cette règle n'est pas seulement demandée au modèle dans un prompt. Elle est appliquée par le serveur, qui contrôle la réponse de l'IA :

  • chaque extrait cité doit exister mot pour mot dans le texte collé, sinon l'élément est déplacé ou marqué « Source non vérifiée » ;
  • chaque responsable doit faire partie des participants détectés dans la conversation ;
  • une mention « Confirmé par » n'apparaît que si chaque confirmation est prouvée par un extrait écrit par la personne nommée.

L'interface montre l'extrait source dans chaque ligne, pour que l'utilisateur puisse vérifier lui-même que rien n'a été inventé.

Le parcours de l'utilisateur

  1. Il colle sa conversation, ou clique sur « Essayer avec un exemple ».
  2. Il clique sur Démêler.
  3. Il lit le plan, corrige ce que l'IA a mal compris (titre, responsable, échéance), coche les tâches faites, assigne un responsable à un point flou pour le transformer en tâche, ou supprime un élément (avec un bouton « Annuler » pendant quelques secondes).
  4. Il exporte le plan en Markdown, en le copiant ou en le téléchargeant.
  5. Le plan reste dans son navigateur : il le retrouve le lendemain matin.

Quand quelque chose tourne mal, l'écran dit clairement ce qui s'est passé, sans jargon technique, et le texte collé n'est jamais perdu : texte trop court ou trop long, service saturé, réseau coupé, quota atteint, réponse illisible, ou conversation sans rien à démêler (ce qui n'est pas traité comme une erreur).

Le design : un carnet de relecture

Je ne voulais pas d'une énième application d'IA violette et dégradée. L'inspiration est celle d'une épreuve d'imprimerie annotée au stylo rouge :

  • fond papier chaud, texte noir encre ;
  • une seule couleur d'accent, un rouge vermillon réservé aux « Points à clarifier », avec un trait vertical dans la marge, comme une annotation de relecture ;
  • une serif éditoriale pour les titres, une sans-serif sobre pour l'interface, une monospace pour les extraits cités ;
  • des séparations par de fines lignes plutôt que des cartes arrondies.

Le logo est un petit fil qui se redresse : démêler.

Comment je l'ai construit

J'ai construit Démêle pendant le hackathon Build With AI: Basics de Devpost, avec le Devpost Learn Skill Pack dans un agent de code. La méthode : planifier avant de coder.

  1. 1-start : l'agent m'a interviewé sur mon idée et mon parcours.
  2. 2-scope : j'ai fixé ce que le projet fait, et surtout ce qu'il ne fait pas (pas de comptes, pas de base de données, pas d'intégration WhatsApp en direct).
  3. 3-prd : j'ai décrit chaque écran, chaque état et chaque cas d'erreur.
  4. 4-spec : j'ai choisi la pile technique et la façon de vérifier la réponse de l'IA.
  5. 5-build : la construction par tranches, en testant chaque morceau avant de passer au suivant.

Les documents scope.md, prd.md et spec.md sont dans le dépôt.

La pile technique : React + TypeScript (Vite), un petit serveur Node/Express, Zod pour valider les données, et l'API Gemini (@google/genai) avec sortie structurée. Pas de base de données : le plan vit dans le navigateur.

Les tests : quatre conversations fictives, chacune dans un format différent (WhatsApp Android, WhatsApp iPhone, format générique, conversation désordonnée) :

  • une conversation propre ;
  • une conversation désordonnée, avec horodatages et réactions ;
  • une conversation volontairement floue, où personne ne s'engage et où aucun responsable ne doit être inventé ;
  • une conversation sans aucune décision, qui doit donner un résultat vide.

Ce qui ne s'est pas passé comme prévu

Un projet raconté sans ses accrocs serait moins honnête, et j'y ai beaucoup appris.

  • Une clé d'API dans un commit. J'avais créé mon fichier .env avant que .gitignore le protège, et il s'est retrouvé dans un commit envoyé sur GitHub. J'ai révoqué la clé, retiré le fichier du suivi et vérifié la protection avec git check-ignore. Depuis, je contrôle chaque commit avant de l'envoyer.
  • Un modèle d'IA qui change sous les pieds. Le modèle prévu dans mon spec (gemini-2.5-flash) n'était plus servi aux nouveaux comptes, et des modèles plus récents renvoyaient des erreurs 503 de saturation. Comme le nom du modèle est une variable de configuration, j'ai pu changer sans toucher au code, puis comparer deux modèles : sur ma conversation floue, gemini-3.5-flash a retrouvé 3 points sur 4, contre 2 sur 4 pour Flash-Lite. J'ai gardé le premier.
  • Une panne réseau prise pour un bug. Une erreur de résolution DNS m'a fait croire que mon schéma de sortie était refusé. En lisant la vraie erreur, j'ai compris que la requête n'était jamais partie. Depuis, l'application distingue réseau, saturation et quota.
  • Un travail mis de côté par l'agent. Un malentendu avec l'agent lui a fait mettre mon travail de côté (git stash). Rien n'a été perdu, mais j'ai appris à lui donner des règles explicites : jamais de commande destructive sans me demander.

Ce que j'ai appris

  • Un plan écrit avant le code évite de reconstruire en cours de route. Chaque décision du PRD s'est retrouvée dans le code.
  • Il ne faut pas se fier à la parole du modèle. Demander à l'IA de ne pas inventer ne suffit pas : il faut vérifier sa réponse côté serveur.
  • Un agent est un collaborateur qu'il faut cadrer. Les règles claires (pas d'appel inutile à l'API, pas de commande git destructive) et les vérifications que je peux relancer moi-même comptent autant que le code produit.
  • Les erreurs font partie du produit. Un bon message d'erreur, qui conserve le texte collé, vaut plus qu'une fonctionnalité de plus.

Limites connues

  • Le plan gratuit de l'API Gemini est limité en requêtes, et le service est parfois saturé.
  • Le texte collé est envoyé à Gemini (Google) pour l'analyse. Démêle n'en conserve rien sur son serveur, et le plan reste dans le navigateur de l'utilisateur.
  • Pas de comptes ni de synchronisation entre appareils : l'application tourne en local.
  • Les conversations très longues sont refusées au-delà d'une limite de caractères, sans découpage automatique.

Et après ?

  • Comptes et synchronisation entre appareils, pour retrouver ses plans partout.
  • Historique des plans et suivi des tâches d'une conversation à l'autre.
  • Niveaux de priorité, rappels et export vers des outils d'équipe.
  • Déploiement en ligne.

Liens


Démêle — the story in short (English)

Problem. Group chats bury decisions and leave nobody sure who owns what. Auto-summaries make it worse by smoothing over the ambiguity.

Idea. Démêle turns a messy group chat or raw meeting notes into three columns: Decisions, Tasks (with owner and deadline), and Open questions: what stayed vague, undecided, contradictory, or ownerless. The third column is the product.

Core rule. The AI never guesses an owner. If nobody clearly committed, the item goes to Open questions. The server enforces it: every quoted excerpt must exist verbatim in the pasted text, every owner must be a detected participant, and every "confirmed by" needs a verifiable excerpt.

Design. An editor's proofreading notebook: paper background, ink-black text, and a single vermilion red reserved for Open questions, like a margin note in red pen.

Built with. The Devpost Learn Skill Pack: scope, PRD and spec written before any code. React + TypeScript (Vite), Node/Express, Zod, and Gemini structured output. The plan stays in the browser.

What I learned. Plan before you build; verify the model's output on the server instead of trusting it; give a coding agent explicit rules; treat error states as part of the product.

Built With

Share this project:

Updates

Submission history