SOSNOTAIRES.COM
et la bibliothèque de formules

UN PEU DE TECHNIQUE

Avant de définir les concepts de notre bibliothèque d'actes, nous allons passer en revue les objectifs, contraintes et possibilités.

Structure d'un acte
Objectifs :
Un acte doit suivre un cheminement, et un seul, toujours le même, avec comme seul objectif : une place pour chaque chose, et chaque chose à sa place.
Il doit répondre aux impératifs suivants :
-extrait d'acte pour l'administration,
-exigences de la fiscalité,
-respect strict de la distinction 1ère partie/2ème partie,
-respect de toutes les législations protectrices du consommateur, sans en rajouter,
-être le reflet clair des conventions des parties,
-en chasser tout ce qui n'a rien à y faire.
Contraintes :
Il n'y a pas de contraintes techniques.
Par contre, il sera peut-être nécessaire de redéfinir avec l'administration l'emplacement exact de certaines clauses et paragraphes.
Possibilités :
Il n'y a pas de limite théorique.
Comme en imprimerie, il y a un "chemin de fer" à définir. Essayons de réaliser un squelette simple et stable, sous forme de déroulement logique du processus de l'acte, avec un début, un cheminement et une fin.

Portabilité
Objectifs :
Le système doit pouvoir fonctionner :
-quel que soit le système d'exploitation (de Windows 95 à Longhorn et autres variantes Windows, en passant par MacOs, Linux, ou autres),
-en version mono-poste, multi-poste (en réseau), via le web, ou à distance,
-sans tenir compte du matériel utilisé.
Contraintes :
La tâche est difficile, et s'il existe actuellement une très grande demande de portabilité, il n'existe pas de solution globale permettant de fonctionner sur tous les systèmes d'exploitation.
Possibilités :
Il est indispensable de s'affranchir des systèmes d'exploitation, et de se retourner vers les solutions utilisées sur le web, où les différents systèmes co-habitent à peu près harmonieusement, par le biais :
-des navigateurs (Internet Explorer, Netscape, Mozilla, FireFox, Eudora et autres),
-de langages spécifiques web (JavaScript, PHP ...) ou de méta-langages dits de description (HTML, XML ...).
Il est tout à fait possible de travailler en mode web client/serveur, sans sortir de l'office, ou même en mono-poste.

Système de travail
Objectifs :
L'office doit pouvoir choisir son système de travail :
-soit avec un simple système traitement de texte,
-soit sous une forme plus évoluée, associée à un logiciel complémentaire et une base de données.
Ce système doit permettre également :
-de passer de l'un à l'autre, sans perte de données,
-la possibilité d'élaborer des sous-produits de manière semi-manuelle ou automatisée.
Enfin, et non des moindres, l'office doit être libre de changer quand il le souhaite de SSII, facilement et sans aucune perte de données ou d'informations.
Contraintes :
Il faut d'office exclure tout système basé sur un logiciel spécifique et des macros.
Par ailleurs, tout n'est pas forcément réalisable en totalité et en même temps :
-un système simple basé sur traitement de texte ne pourra pas compléter une base de données,
-mais le système plus évolué peut récupérer les données plus tard, et reconstituer après coup, la base de données (à condition que les balises XML aient été conservées).
Possibilités :
L'acte doit être :
-constitué de modules préétablis, à utiliser tels quels, à modifier ou à compléter,
-structuré avec des balises HTML, destinées à assurer la présentation,
-structuré avec des balises XML, qui permetront des fusions avec une base de données, ou d'exploiter ces données après coup, et ce, quels que soient les logiciels qui y sont ou seront rattachés.

Structure des fichiers
Objectifs :
Les fichiers doivent pouvoir :
-être lus, créés ou enregistrés par n'importe quel logiciel de traitement de textes, même basique, tournant sur n'importe quel système d'exploitation,
-être lus ou sauvegardés quel que soit le lieu ou le support (mono-poste, réseau, via internet ou à distance),
-tenir compte de l'existant informatique,
-tenir compte de son évolution prévisible.
Contraintes :
La quasi totalité des traitements de texte actuels ont un format "propriétaire", c'est à dire qu'ils ne peuvent être lus ou créés qu'à partir de ce logiciel, ou au moyen de filtres.
Possibilités :
Il est possible d'utiliser :
-soit le format RTF, dont les codes de mise en page sont divulgués,
-soit OpenOffice, dont le code est OpenSources,
-soit des fichiers au format texte, récupérables par tous les traitements de texte, et ne comportant aucune instruction binaire ou propriétaire, ni aucun code parasite.

Assemblage des fichiers
Objectifs :
L'assemblage de l'acte (ou des sous-produits), doit pouvoir s'effectuer :
-de manière manuelle,
-de manière assistée,
-ou de manière automatique,
-sur le poste, sur le serveur ou à travers le web.
Contraintes :
Les traitements de texte ne permettent pas la concaténation de plusieurs fichiers pour en reformer un seul. Cela nécessite donc de passer par une étape intermédiaire d'assemblage, dans un format autre que celui utilisé par les traitements de texte.
Possibilités :
Il est tout à fait possible :
-de concaténer des fichiers écrits en mode texte,
-de conserver, sans les détruire, les balises HTML ou XML qui s'y trouvent,
-de donner à ces fichiers l'extension que l'on souhaite, et sur ses propres critères de "commodité",
-d'encapsuler les fichiers sélectionnés, et dans l'ordre sélectionné, dans un plus grand document, HTML ou XML.
La fusion devra s'accomplir au moyen d'un langage utilisable sur les serveurs Internet, et en usage chez l'hébergeur du site (si l'on passe par un site).

Mise en page
Objectifs :
L'objectif final est :
-l'édition de l'acte lui-même (et de ses dérivés), au moyen de n'importe quel traitement de texte classique,
-son stockage, éventuellement sous un autre format, et quel que soit le support utilisé.
Contraintes :
Les fichiers en format texte préconisés plus haut, sont destinés à produire ce que l'on appelle un "code source" (ils sont lisibles, mais affichés en mode texte, comportant toutes les instructions sous forme de balises).
Possibilités :
C'est l'encapsulation des fichiers (avec les instructions qu'ils contiennent) qui permettra de leur donner forme, de les afficher, de les imprimer et de les sauvegarder sous un autre format.
Il est possible d'utiliser :
-soit une encapsulation au format HTML, qui permettra de lire le fichier assemblé avec votre navigateur habituel, et même de le récupérer au moyen de votre traitement de texte habituel, la plupart sachant le faire,
-soit une encapsulation à partir de XML, associé à XSLT ou FO, qui permettra un affichage et une sortie directes en différents formats standards (RTF ou PDF).

Super bible
Objectifs :
Pourquoi s'arrêter là ?
-rien n'oblige chaque office à détenir une bibliothèque de formules,
-celle-ci pourrait parfaitement être centralisée sur un serveur Internet,
-les notaires n'auraient plus à se préoccuper de son acquisition ni de sa maintenance,
-elle serait constamment à jour,
-les actes pourraient être réalisés et assemblés "à distance".
Contraintes :
Les seules restrictions (outre le fait qu'une seule bibliothèque pour tous les notaires ne soit pas forcément à recommander), sont celles relatives à la sécurité de tout site web.
Possibilités :
C'est encore Internet qui apporte la solution :
-il n'existe aucune difficulté à sélectionner vos clauses, et à assembler les actes,
-cela est réalisable très rapidement,
-les actes reconstitués (ou les cadres), sont parfaitement récupérables sur votre système.
Pour preuve, c'est ce qui est mis en application ici.

CONCEPTS

La synthèse des réflexions ci-dessus conduit à l'élaboration de 2 concepts :

Concept 1 - Structure des actes
Les actes sont structurés en modules autonomes et indépendants, non liés entre eux.
Le "découpage" proposé pour un acte de vente est le suivant :

1ère partie
extrait d'acte module 1 en-tête nom du notaire
module 2 éléments constitutifs identification des parties, désignation des biens, rappel de publication
module 3 conventions annexes emprunt par l'acquéreur, constitution de servitudes, ...
module 4 jouissance propriété, jouissance
module 5 prix prix, modalités de paiement
module 6 fiscalité frais, déclarations fiscales, plus-values
variables module 7 formalités préalables compromis, notes techniques, offre de prêt, préemption, HF
module 8 signataires présence-représentation, énonciation des pouvoirs, annexes, remise de pièces
semi-constantes module 9 consentement accord des parties
module 10 paiement du prix paiement comptant - ou promesse d'emploi, PPD, HC
2ème partie
constantes module 11 conditions conditions générales - conditions conventions annexes
module 12 clôture formalités, domicile, affirmation de sincérité
module 13 réception notaire - ou clerc habilité
annexes
conditions/ garanties module 14 conditions conditions générales de la vente
module 15 garanties garanties par le vendeur / par le constructeur, déclarations par le vendeur

Cette structure est facilement transposable à tous types d'actes.

Concept 2 - Architecture
L'architecture proposée pour la bibliothèque de formules, est la suivante :
-le minimum de modules pour le maximum de formules,
-des modules constitués d'entités ou d'ensemble, comportant le maximum d'éléments, (par exemple regroupement en un seul module de ancien propriétaire, nouveau propriétaire, désignation et origine), en fonction du type d'acte,
-les modules sont stockés sur le disque dur de l'office, ou sur un site externe, où ils sont classés en dossiers et sous-dossiers,
-ils sont établis en mode texte, exploitables par n'importe quel traitement de texte (dont NotePad),
-ils comportent leur propre structure de mise en page, au moyen de balises HTML,
-ils comportent également des balises XML (provisoirement non utilisées), qui permettront tous traitements à l'avenir, par récupération des données "à l'envers",
-la hiérarchie de ces fichiers est logique, et leur dénomination codifiée de manière mnémonique (afin d'en faciliter l'accès, la mise à jour et la maintenance),
-l'assemblage s'effectue, soit de manière manuelle, par les noms des fichiers, soit de manière automatique (à partir d'une page de sélection), en faisant appel au langage PHP, et de manière totalement transparente pour l'utilisateur,
-les fichiers sélectionnés sont regroupés et encapsulés, dans l'ordre de la sélection, à l'intérieur d'un plus grand fichier HTML (pour le moment, mais qui pourra sans aucune difficulté être remplacé par une encapsulation XML le moment venu),
-le résultat (le cadre complet de l'acte), est affiché dans votre navigateur, sans aucune manipulation,
-il ne reste qu'à le récupérer, à le transformer en un document d'un autre format, en vue de le compléter.

Observations
Ce dossier (et la présente page), ne traitent que de la bibliothèque d'actes notariés, et non d'un système automatisé de rédaction d'actes.
En l'état actuel, si l'assemblage peut s'effectuer automatiquement, en fonction des sélections effectuées par l'utilisateur, cela ne permet d'établir que le cadre de l'acte, avec ses différentes clauses, qu'il suffira de compléter manuellement, au moyen de votre traitement de texte, pour aboutir à l'acte fini.
Les sous-produits pourront être obtenus tout aussi facilement, et en utilisant la même méthode (ou un simple copier-coller du début de l'acte).
Un système plus évolué nécessite :
-la création d'un logiciel spécifique, en vue de compléter les fichiers auxquels nous ont habitués nos SSII,
-la mise en place d'une base de données (à supposer que cela soit indispensable), ou la gestion des données par notre logiciel spécifique,
-un assemblage automatisé des données issues de ces fichiers, à l'intérieur des balises XML en attente.

Nota
Le système actuel peut déjà rendre de très grands services en l'état, bien que nombre d'entre nous aient perdu l'habitude de travailler ainsi.
Cela doit nous amener à nous poser quelques questions :
-un système automatisé est-il vraiment indispensable,
-sommes-nous irrémédiablement incapables de rédiger un acte, s'il comporte des cases à compléter, plutôt que des fichiers séparés (il faut de toute manière retaper les variables, quel que soit le système adopté),
-ne serait-il pas indispensable de redonner à nos clercs l'art de la rédaction, plutôt que de les confiner dans un rôle de subalterne vis-à-vis de la machine.

Point de vue du web-master
On peut résumer les avantages d'un tel système :
-portabilité complète des fichiers (ils sont en mode texte, lisibles par n'importe quel logiciel de traitement de texte, ou même un simple éditeur de texte rudimentaire),
-lisibilité totale des fichiers, même par un néophyte (ils ne sont pas encombrés par la masse d'instructions incompréhensibles générées par les traitements de texte - à supposer qu'on puisse avoir accès au code),
-gain en taille considérable (un fichier "texte" prend 3 à 4 fois moins de place qu'un même fichier réalisé par un traitement de texte classique -qui génère énormément de codes parasites et incompréhensibles-),
-on s'affranchit totalement du système d'exploitation (le serveur est sous Linux, et vous pouvez parfaitement travailler sous Windows ou MacOs, à votre choix),
-la pérennité est totale (tous les fichiers utilisés pourront être utilisés tant qu'existeront l'écriture et les alphabets),
-la technique est facilement transposable pour tous nos besoins (comptabilité, taxe, paye, gestion, etc...)
-l'inter-opérabilité entre tous les programmes est totale, le "coeur" (et les données), étant utilisable par tous, sans aucune modification.
C'est probablement la seule solution "d'avenir".

Il serait possible d'aller plus loin dans l'organisation du système, et notamment par la multiplication des modules. Mais il semble indispensable de conserver présents à l'esprit 2 principes :
-le minimum de modules pour le maximum d'actes,
-"faire simple", et savoir jusqu'où ne pas aller trop loin.

Dernière minute
Au cours de ce dossier, il est préconisé la mise en place d'un logiciel de traitement de texte simple, débarrassé de tout l'inutile, et surtout permettant l'export au format xml (en produisant un fichier html, lisible par tous les navigateurs).
Et bien, ce logiciel existe, et en français :
Il s'agit d'ABIWORD, téléchargeable gratuitement sur www.abisource.com.
Et il est presque parfait :
-le code source généré est encore un peu lourd (il n'a pas été conçu spécifiquement pour la France),
-mais il est en Open Source, et donc modifiable,
-il exporte de plus, pour les nostalgiques, en différents formats (DOC, RTF).

Peut-être que nos SSII pourraient s'y rallier d'un commun accord, et développer ensemble des applications spécifiques à la profession.
Et là, ce serait parfait.
Mais le choix peut tout aussi bien porter sur OpenOffice.org, également gratuit et en OpenSources, un peu plus lourd -il s'agit d'une suite bureautique complète-, avec des capacités beaucoup plus étendues (voir sur ce site MELUSINE , dossier consacré à l'Open Sources).


page d'accueil bibliothèque d'actes notariés