--- title: "Comment nous travaillons" code: "RP-0001" language: "fr" canonical: "https://regentspark.ai/fr/RP-0001/" html: "https://regentspark.ai/fr/RP-0001/" markdown: "https://regentspark.ai/fr/RP-0001.md" updated: "3 May 2026" --- # Comment nous travaillons **Version :** 2.2 **Date :** 3 mai 2026 **Statut :** Document vivant *La philosophie de recherche derrière Regent's Park.* --- ## Le problème d'abord, toujours Chaque recherche suit le même arc : **1. Quel est le problème ?** Commencer par quelque chose qu'une personne reconnaît. Pas une lacune technique, mais une frustration humaine. « Je ne retrouve pas mes affaires. » « Je dois me connecter partout. » « Mon collaborateur ne voit pas ce que je fais. » Si vous ne pouvez pas expliquer le problème à quelqu'un autour d'un café, vous ne le comprenez pas encore. **2. Quel est le modèle mental ?** Comment les gens pensent-ils déjà à cela ? Quelles métaphores utilisent-ils ? « C'est comme une pièce » ou « c'est comme connaître le nom de quelqu'un ». Ancrer la pensée dans la manière dont les humains naviguent dans le monde physique, puis montrer où l'informatique rompt cette intuition. **3. Raisonner par analogie** Trouver des choses qui semblent claires et évidentes, des choses que les humains comprennent depuis des millénaires, et s'en servir comme lentilles. Comment fonctionnent les pièces ? Les relations ? La mémoire ? Puis : comment la version informatique se compare-t-elle ? Où casse-t-elle, et pourquoi ? **4. Qu'est-ce qui existe aujourd'hui ?** Cartographier honnêtement le paysage. Quels outils, protocoles et standards essaient de résoudre cela ? Où réussissent-ils ? Ne pas sélectionner seulement les échecs pour justifier une thèse : évaluer vraiment ce qui marche et ce qui ne marche pas. **5. Que proposons-nous ?** Seulement maintenant, proposer une direction. Pas une spécification. Pas une architecture. Une manière de penser qui découle naturellement du problème et des analogies. Le lecteur devrait avoir l'impression qu'il aurait pu y arriver lui-même. **6. Qu'est-ce qui est difficile ?** Enfin : quels sont les vrais défis ? Qu'est-ce qui est réellement difficile à construire ? Cette section existe pour les constructeurs, mais elle ne devrait jamais apparaître avant que le lecteur comprenne pourquoi la chose doit exister. **L'ordre compte.** Si l'on commence par les détails techniques, on obtient une réponse en quête de question. Si l'on commence par le problème, les détails techniques deviennent inévitables. --- ## Recherche d'abord, écriture ensuite Avant d'écrire un essai ou de formuler une affirmation, il faut examiner le territoire. Lire ce qui existe. Comprendre qui a essayé quoi et où les tentatives ont bloqué. C'est une discipline, pas une étape que l'on saute parce que l'idée paraît évidente. Nous produisons deux types de documents : - **Les enquêtes** cartographient un paysage. Elles sont descriptives : ce qui existe, ce qui a été essayé, ce qui marche, ce qui ne marche pas. Une bonne enquête est stable : le paysage ne change pas parce que nous avons une opinion dessus. - **Les propositions** avancent une thèse. Ce sont nos idées : provisoires, évolutives, construites sur les enquêtes. Une proposition doit dire honnêtement sur quoi elle s'appuie et où elle spécule. Ces deux formes ne devraient pas être mélangées dans le même document. Si nous décrivons ce qui existe, nous enquêtons. Si nous défendons ce qui devrait exister, nous proposons. Le lecteur doit toujours savoir ce qu'il lit. --- ## Relier les points, pas inventer Ce problème est trop vaste pour être résolu seul. Beaucoup de personnes travaillent sur des morceaux depuis des décennies. Notre contribution, si nous en avons une, consiste à relier des travaux qui ne l'ont pas encore été, à trouver des questions qu'il est probablement bon de poser, et à proposer d'où pourraient venir les réponses. Il existe parfois des protocoles et systèmes qui montrent certaines des propriétés que nous cherchons, mais auxquels il en manque d'autres. Nous les signalons honnêtement. Nous essayons de voir la forme de ce qui manque. --- ## Ce que nous écrivons, et ce que nous n'écrivons pas Nous écrivons des problèmes que tout le monde peut reconnaître. Des analogies qui rendent l'abstrait sensible. Des évaluations honnêtes de ce qui existe déjà. Des directions qui paraissent évidentes après coup. De la profondeur technique après la clarté conceptuelle. Nous n'écrivons pas des spécifications de protocole avant d'avoir des utilisateurs. Des documents d'architecture avant d'avoir des prototypes. Des explications qui commencent par le jargon et ne parlent qu'aux initiés. Ou des solutions avant d'avoir mérité la confiance du lecteur sur la réalité du problème. --- ## Démontrer une expérience, pas une architecture Quand nous produisons des démonstrations conceptuelles, ce ne sont pas des preuves techniques de concept. Elles montrent ce que l'expérience pourrait faire sentir si les pièces manquantes existaient. La question à laquelle répond une démonstration est : « à quoi cela ressemblerait-il ? », pas « comment l'implémenteriez-vous ? » C'est important parce que le manque que nous étudions est expérientiel. Les gens ne sentent pas l'absence d'un protocole. Ils sentent l'absence de pouvoir prendre leur travail et le déplacer ailleurs. Les démonstrations doivent rendre cela sensible. Pour l'instant, le programme de recherche lui-même est ce qui se rapproche le plus d'une démonstration : un humain et une IA qui partagent un espace de travail, accumulent une mémoire commune, et partagent le travail au fur et à mesure qu'il prend forme. L'expérience de le faire est une donnée de recherche. --- ## Quatre tests Chaque recherche est testée contre : 1. **Le test du café** : pourriez-vous l'expliquer à un ami intelligent autour d'un café ? Sinon, réécrivez. 2. **Le test du « et alors ? »** : le lecteur comprend-il pourquoi cela compte pour lui, pas seulement pour nous ? 3. **Le test d'honnêteté** : avons-nous mis nos hypothèses à l'épreuve ? Avons-nous représenté équitablement les alternatives ? 4. **Le test du constructeur** : après lecture, quelqu'un saurait-il quoi construire ? --- ## Humain + IA Regent's Park est une expérience de recherche semi-autonome. Nico dirige : il choisit les problèmes, façonne les arguments, prend les décisions éditoriales. Homard, partenaire de recherche IA, coordonne : recherche, rédige, maintient le site, gère le corpus. Le processus est collaboratif, pas automatisé. Chaque décision importante implique les deux. L'IA ne partage pas de travail sans revue humaine. L'humain ne perd pas le contexte parce que l'IA le maintient. Nous pensons que cela fait lui-même partie de la recherche. Si les primitives manquantes de l'informatique incluent le contexte partagé, la mémoire et la collaboration, alors un programme de recherche où un humain et une IA partagent un espace de travail persistant, accumulent une mémoire commune et produisent un vrai résultat est une preuve que ces primitives comptent. Nous n'étudions pas seulement le problème. Nous vivons dedans. --- 🌳