Ce dossier jette les bases de bibliothèques de formules, sur un concept totalement nouveau.
Il reste à développer le système, et à l'étendre, soit par le webmaster, soit en partenariat, sur les principes suivants :
Court terme
Les bases et les principes sont posés.
Ils semblent suffisamment solides et stables, sans nécessiter de modifications.
Par contre, avant d'aller plus loin, il reste à fignoler :
-la mise en page, assurée pour le moment au moyen d'instructions CSS, en vue de l'incorporation des fichiers dans un document HTML,
-de définir les balises XML à utiliser (bien qu'il puisse toujours en être ajouté d'autres par la suite, sans difficulté).
-de définir la structure et la hiérarchie des fichiers (dossiers/sous-dossiers).
Ensuite, pourra commencer le travail d'écriture des modules destinés à enrichir notre bibliothèque.
Jusque-là, nous sommes toujours dans l'optique d'un système d'aide à la rédaction des actes, avec utilisation (et récupération), de cadres type pré-établis.
Il restera à mettre en place une table des incomptabilités, afin d'assurer la cohésion entre les différents modules, en suite d'une série de sélections.
Le système d'assemblage manuel et à la demande sera amélioré (c'est vous qui décidez des clauses à assembler, et dans quel ordre).
Moyen terme
Il serait dommage d'en rester là, et une nouvelle étape pourrait être franchie, afin d'automatiser la conception et la rédaction des actes, au moyen de la mise en place d'un système de fichiers (et d'une base de données, si cela s'avère indispensable), comme le font la plupart des systèmes actuels.
Cela suppose :
-d'exploiter les ressources du XML, avec mise en place dans notre document, d'une gestion de ce document (au moyen de ce que l'on appelle une DTD),
-l'écriture d'un logiciel spécifique, pour la gestion de nos fichiers,
-l'amélioration de la mise en page, en associant XML et XSLT, en vue de sortir des documents directement au format RTF ou PDF.
Une technique intermédiaire est envisageable. Elle consiste à travailler par modules, que l'on complète au fur et à mesure des besoins ou des possibilités. On peut commencer par compléter état civil, désignation et origine, et l'enregistrer, puis plus tard, compléter le module formalités préalables, etc....
Ce sont ces modules complétés que l'on conserve et enregistre (inutile d'enregistrer et de sauvegarder des constantes, à moins qu'elles aient subi des modifications).
L'assemblage s'effectue au dernier moment, uniquement pour les besoins de la mise en page et de l'impression.
C'est une méthode de travail plus agréable que de travailler sur un acte complet, et cela représente un gain de place non négligeable.
Long terme
Le système ne se limite pas au traitement des actes. Ses possibilités sont considérables.
On peut parfaitement réaliser sur les mêmes principes (et en exploitant les mêmes fichiers), la comptabilité, la taxe, la paye, la gestion ... Il n'y a pas de limites (si ce n'est qu'il faut se souvenir que nos fichiers sont écrits en mode texte, lisibles par n'importe qui, et qu'il sera donc nécessaire de penser à leur cryptage).
En effet, n'oublions pas que nous travaillons sur des échanges de données normalisés au moyen de balises XML, ce qui rend les données exploitables quel que soit le programme utilisé.
Ainsi (à titre d'exemple) :
-la formule d'acte que vous avez choisie, peut comporter, en fonction de son type, une balise XML, qui peut être exploitée par le logiciel de taxe, puis à son tour par la comptabilité, et un logiciel de gestion intégré ...
Tous les programmes peuvent donc être reliés à un ou plusieurs fichiers, en retirer des données, les exploiter, puis les réexpédier après traitement, et ainsi de suite, en cascade et de manière transparente.
Par ailleurs, le XML comporte la possibilité (non négligeable), d'effectuer des calculs simples.
Le travail le plus urgent (et le plus important), est donc la codification de toutes ces balises, afin que tous les concepteurs de logiciels puissent s'y référer.
Le travail de programmation viendra ensuite.
Autres professions
Un tel système n'intéresse pas uniquement le notariat, mais toutes les professions manipulant des blocs de données, à assembler et mettre dans un certain ordre, en fonction de critères (avocats, huissiers, ...).
Il pourrait donc être extrèmement utile de les intéresser au projet, chacun pouvant développer ses propres balises XML, en fonction de ses besoins spécifiques.
Quel logiciel
Jusqu'à ce jour, nous utilisons tous des traitements de texte (de préférence payants, et à peu prêt tous le même, on ne sait trop pourquoi..., alors qu'il en existe d'excellents gratuits).
Mais ces logiciels sont tous devenus des gros dévoreurs de capacité mémoire, alors que nous n'utilisons qu'à peine 5 à 8% de leurs capacités, et leur ergonomie, à laquelle nous avons tous dû nous plier, n'est pas forcément exempte de critiques.
Ainsi qu'on l'a vu, autour de ces traitements de textes, ont été développées des macros, permettant l'assemblage de nos actes. Et nous devenons ainsi prisonniers de ces traitements de texte (mais c'est peut-être leur objectif?).
Il serait possible de se débarasser de tout cela, facilement.
Nos besoins sont de 2 ordres :
-la gestion de documents en mode texte, dans laquelle sont incorporées des balises d'instructions,
-la gestion des fichiers (création, modification), tant des formules de base, que des données devant servir à l'établissement de nos actes.
Ce sont donc des besoins basiques, et qui ne nécessitent pas de disposer de centaines de possibilités que l'on n'utilisera jamais.
La seule difficulté est celle du support du système de travail : il est très difficile (et sans doute désagréable), pour un néophyte, de travailler sur du code source (c'est à dire les instructions qui permettront d'établir votre document fini).
La solution est encore une fois de se retourner vers les techniques web, et de s'inspirer de certains éditeurs HTML, XML et autres langages : le logiciel comporte 2 volets, l'un avec le code source, si l'on veut intervenir directement dessus (ce qui permet vraiment du cousu main), et l'autre en mode visionneur, qui permet d'afficher le résultat.
On pourrait ainsi disposer d'un logiciel très simple (et rapide), limité aux fonctions essentielles, s'inspirant par exemple de Web Expert, et distiguant clairement (par le biais de couleurs), les instructions de code, par rapport au texte lui-même.
Et rien n'oblige à imposer un seul logiciel, ni un seul système : seul le "coeur" (structure des données) est à respecter.
Ainsi, chaque SSII peut parfaitement écrire son programme, comme elle le pense, avec le look , sur le système d'exploitation et avec le langage de son choix (pas forcément orienté Internet, pour une fois - il existe d'excellents langages "classiques").
Par ailleurs, n'oublions pas que ce système génère lui-même sa propre mise en page. Nos traitements de texte ne nous seront plus alors d'une grande utilité, car ils ne serviront que pour l'édition finale (et là aussi, on pourrait s'en passer).
Qui
Les questions qui se posent maintenant, sont de savoir :
-qui va procéder au travail de codification XML,
-qui va réaliser le (ou les) programmes d'application.
Le web master peut évidemment aller un peu plus loin, mais il ne peut pas tout faire seul.
Transition
Tout ne se fera pas en un jour.
Les logiciels distribués par nos SSII ont nécessité du temps et de l'investissement, et il n'est pas envisageable de passer d'un système à un autre, sans transition.
Celle-ci pourrait être assurée sans difficulté, par la mise au point de "passerelles", qui viendraient se greffer sur les logiciels existant actuellement, afin de permettre, dans un premier temps, de réaliser des échanges de données entre tous les différents logiciels existants, et l'administration.
Il reste à se mettre d'accord sur les normes de ces passerelles, et sur les caractéristiques d'encapsulage des données.
L'administration Belge communique les caractéristiques de ses données (sur des bases XML). Cela est-il irréalisable en France ?
Il semble irréaliste d'attendre de nos SSII qu'elles mettent ces normes au point, et difficile de leur demander de se débrouiller seules pour le faire.
C'est à la profession, et à nos instances, de provoquer la mise au point de ces normes, en commun accord avec tous nos partenaires.
Cela se produira-t'il un jour ?
Point de vue
A ce niveau, c'est encore une fois à toute la politique informatique de la profession qu'il faut réfléchir.
Prenons en exemple notre comptabilité.
Nous devons obligatoirement utiliser des programmes dits "habilités" (sous peine de sanction...).
Pourquoi pas.
Mais il faut savoir que l'habilitation repose uniquement sur les "sorties", et donc les documents édités (pas toujours avec bonheur -il suffit de regarder nos tableaux de bord-, ni dans un souci d'économie de papier).
Les données (qui sont pourtant le coeur d'une comptabilité), sont incompatibles, et ne peuvent être lues ni exploitées d'un programme à l'autre.
La profession elle-même est incapable de contrôler ces données ou d'y accéder (sphynx s'y est cassé les dents), ce qui est un comble pour des programmes habilités.
Or, des solutions existent (XML, et les principes du présent dossier).
C'est peut-être le moment de mettre en chantier un "grand projet des Notaires de France", débouchant sur un projet infomatique d'ensemble cohérent et à long terme.
