Contrats et architecture

Anatomie d'un contrat

contrats/CT-2025-040-licence-logiciel.txt (début)

CONTRAT DE LICENCE DE LOGICIEL
Référence : CT-2025-040
Type : licence
Parties : Atelier Nova ; Kerlogic
Date de signature : 2025-09-01

Article 1 – Objet
1.1 Kerlogic concède à Atelier Nova une licence d'utilisation non exclusive du logiciel ...
Article 2 – Durée
2.1 La licence est concédée pour un (1) an à compter du 1er septembre 2025, renouvelable ...

Trois couches d'information, trois traitements :

Couche	Exemple	Traitement dans le lab
En-tête (métadonnées)	type `licence`, partie `Kerlogic`, date	colonnes SQLite, filtres `WHERE`, ajoutées au contexte
Articles	« Article 4 – Résiliation »	un morceau par article : l'unité de sens
Clauses	« 4.1 Chaque partie peut… »	jamais coupées : un article trop long est divisé entre deux clauses

Une métadonnée est une information sur le document (qui, quoi, quand), par opposition à son contenu. Elle ne se « cherche » pas par similarité : elle se filtre, exactement comme une colonne en SQL.

Les trois familles de questions

flowchart TD
  Q["Question sur les contrats"] --> A["Ciblée : préavis du contrat Kerlogic ?"]
  Q --> B["Comparative : préavis des contrats de prestation ?"]
  Q --> C["Synthèse : tableau de tous les contrats"]
  A --> A1["filtre partie=Kerlogic + top-k"]
  B --> B1["filtre type=prestation + 2 morceaux PAR contrat"]
  C --> C1["1 extraction structurée par contrat"]

Ciblée : un contrat, un fait. Le danger est de répondre avec la clause d'un autre contrat : tous ont un article « Résiliation ».
Comparative : plusieurs contrats, le même fait. Un top-4 global risque de ramener 3 morceaux du même contrat et d'en oublier un.
Synthèse : tous les contrats, plusieurs faits. Ce n'est plus de la recherche : on lit chaque contrat entier (ils sont courts) et on extrait des champs.

Pourquoi un top-k global est-il risqué pour « Compare les préavis des contrats de prestation » ?

La partie « Kerlogic » est-elle mieux traitée par un filtre ou par la similarité ?

Le corpus fictif

make_contracts.py décrit chaque contrat en données Python et l'écrit en texte :

files/make_contracts.py (extrait)

    {"fichier": "CT-2025-040-licence-logiciel.txt", "titre": "CONTRAT DE LICENCE DE LOGICIEL",
     "ref": "CT-2025-040", "type": "licence", "date": "2025-09-01",
     "parties": ["Atelier Nova", "Kerlogic"],
     "articles": [
         ("Objet", ["Kerlogic concède à Atelier Nova une licence d'utilisation ..."]),
         ("Durée", ["La licence est concédée pour un (1) an ..."]),
         ...

Le contrat de maintenance a volontairement un article « Niveaux de service » de 5 clauses, plus long que la limite de 500 caractères : il servira à tester le découpage entre clauses.

Exercice : écrire les questions de référence

Pour chacune des trois familles, écrivez une question sur ce corpus et indiquez ce qu'une bonne réponse doit contenir (contrat et preuve textuelle).

Voir la solution

Famille	Question	Attendu
ciblée	« Quel tribunal est compétent pour le contrat de licence ? »	CT-2025-040, « tribunal de commerce de Rennes »
comparative	« Compare les préavis de résiliation des contrats de prestation. »	CT-2025-014 « trois (3) mois » et CT-2025-022 « un (1) mois »
synthèse	« Tableau durée / préavis / montant de tous les contrats »	une ligne par contrat (5 lignes)

C'est exactement le format de golden.json : une preuve (sous-chaîne exacte) par contrat attendu. Elle permet de mesurer le rappel quelle que soit la façon de découper.

Résultat obtenu

Exécution réelle du 2026-10-15 :

$ python make_contracts.py
écrit contrats/CT-2024-031-location-entrepot.txt
écrit contrats/CT-2025-014-maintenance-logiciel.txt
écrit contrats/CT-2025-022-nettoyage-locaux.txt
écrit contrats/CT-2025-040-licence-logiciel.txt
écrit contrats/CT-2025-041-accord-confidentialite.txt

Je sais faire

Distinguer métadonnées, articles et clauses dans un contrat
Classer une question en ciblée, comparative ou synthèse
Choisir entre filtre et similarité pour une contrainte donnée