ResearchGo

Le problème

Les soumissions académiques passent par des fils d'e-mails et des tableurs. Les versions, les commentaires des relecteurs et les exigences des revues divergent dès que plus d'une personne est impliquée, et l'équipe éditoriale répond à la main aux mêmes questions à chaque fois : quelle est cette version, qu'est-ce qui a changé, les références sont-elles correctes, quelle revue convient ?

Comment c'est construit

Une application Next.js sur Supabase, avec toutes les données conservées dans l'UE. Les auteurs se connectent avec ORCID ou par e-mail et déposent un manuscrit en PDF ou en Word. Un worker Python (FastAPI) le parse dès son arrivée, les PDF via GROBID, et renvoie le texte structuré par un callback signé et horodaté qui rejette les jobs falsifiés ou rejoués. Chaque parsing réussi devient une nouvelle version, stockée chiffrée, mais seulement si le texte a réellement changé. L'équipe éditoriale compare deux versions au choix avec un suivi des modifications façon Word, vérifie les citations dans le texte par rapport à la liste des références, et reçoit des suggestions de revues classées par proximité sémantique, grâce à des embeddings calculés sur notre propre worker avec les données de revues d'OpenAlex. Les paiements passent par Stripe.

Les décisions qui ont compté

• Pas de modèle de langage là où une règle suffit

  Le suivi des modifications et la vérification des références sont du code déterministe, sans IA. L'équipe éditoriale doit pouvoir se fier à un diff, et une règle donne la même réponse à chaque fois.

• Les manuscrits ne quittent jamais nos serveurs

  Le matching de revues calcule l'embedding de l'article sur notre propre worker, donc aucun texte de manuscrit ne part chez un tiers. Le classement repose uniquement sur la similarité. L'indexation, le libre accès et les frais s'affichent comme des étiquettes et ne changent jamais l'ordre.

• Chaque job est signé

  Les jobs entre l'application web et le worker portent une signature HMAC et un horodatage. Un job falsifié ou rejoué est rejeté, et un worker qui plante en plein job ne fait pas perdre sa place au manuscrit.

Code tiré du dépôt

1function diffParagraphPair(before: string, after: string): DiffSegment[] {
2  return diffWordsWithSpace(before, after).map((part) => ({1
3    op: part.added ? "ins" : part.removed ? "del" : "equal",
4    text: part.value,
5  }));
6}
7 
8export function diffManuscripts(before: string, after: string): DiffResult {
9  const a = splitParagraphs(before);
10  const b = splitParagraphs(after);
11  // …
12  const parts = diffArrays(a, b);2
13  let i = 0;
14  while (i < parts.length) {
15    const part = parts[i];
16    if (!part) break;
17    if (!part.added && !part.removed) {
18      // …
19      i++;
20      continue;
21    }
22    const next = parts[i + 1];
23    const paired = Boolean(part.removed && next?.added);3
24    const removedList = part.removed ? part.value : [];
25    const addedList = part.added ? part.value : paired && next ? next.value : [];
26 
27    const pairs = Math.min(removedList.length, addedList.length);
28    for (let k = 0; k < pairs; k++) {
29      const segments = diffParagraphPair(removedList[k] as string, addedList[k] as string);
30      paragraphs.push({ kind: "changed", segments });
31      // …
32    }
33    // …
34    i += paired ? 2 : 1;
35  }
36 
37  return { paragraphs, summary };
38}

Où en est le projet

Développée, la plateforme en est aux dernières vérifications. Le lancement aura lieu dès qu'elles seront terminées.