Le premier domaine vers lequel les Legaltech se sont engouffrées pour pénétrer le marché du droit est celui de l’automatisation de la rédaction des actes.

Cette automatisation offre de nombreux avantages :
• un gain de temps évident ;
• une réduction du risque d’erreurs.

A l’usage, les solutions existantes restent cependant limitées ; seuls des actes relativement simples bénéficient de cette automatisation. Un poids plus important des professionnels du droit dans leur développement permettrait sans doute d’améliorer leurs performances.
Cependant, l’une des difficultés faisant obstacle à un investissement personnel accru de la part desdits professionnels dans le développement de solutions de rédaction d’actes performantes est leur méconnaissance des principes régissant le fonctionnement de ces solutions. Le présent article a pour objet de leur présenter sommairement quelques-uns de ces principes et de formuler quelques préconisations.

Par Vincent Billette, Avocat.

1 - Les modèles d’actes, support du programme.

Une erreur courante faite par les juristes participant à un projet d’application de rédaction d’actes consiste à préparer une maquette contenant des options et des blancs, puis à la communiquer à un développeur accompagnée de l’instruction suivante : « faites-moi un logiciel avec ça ».

Si cette maquette n’a pas été conçue en pensant à la façon dont le logiciel va la manipuler, le processus sera chaotique et le résultat au mieux insatisfaisant. Et le juriste aura une lourde part de responsabilité dans cet état de fait.

Pour éviter cela, il importe que les professionnels du droit comprennent comment fonctionne un logiciel.

1.1 - "Think like a computer scientist".

Ce titre d’une série d’ouvrages de référence du développeur américain Allen B. Downey rappelle que la rédaction de code informatique impose de structurer sa pensée d’une certaine façon.

Ce conseil s’adresse certes d’abord au développeur.

Cependant, lorsqu’un juriste rédige des maquettes d’actes qui auront vocation à être utilisées par un logiciel, il est essentiel de rappeler qu’il doit lui aussi adopter ce schéma de pensée : il lui faut apprendre à raisonner non seulement en droit mais aussi en développeur - et ce à toutes les étapes de son travail.

1.1.1 - La programmation orientée objet.

Un code informatique s’est longtemps présenté sous une forme monolithique : un fichier contenant des lignes d’instructions chacune étant numérotée.

Les langages informatiques orientés objet qui se sont développés dans les années 90 sont différents.

Supposons que le programme ait besoin de répéter assez souvent la même opération, par exemple calculer le montant du capital d’une société.

Le capital est égal au produit du nombre de titres et de leur valeur nominale (sauf cas particulier de la société constituée avant l’entrée en vigueur de l’Euro dont le capital n’aurait pas été converti).

A chaque fois que le programme a besoin de retrouver la valeur du capital, il est possible d’insérer dans le code une équation telle que capital = nombreparts x valeur nominale ; mais cela est vite répétitif.

Dans un langage orienté objet, l’équation n’est rédigée qu’une seule fois :
 l’équation est un objet ;
 lorsque l’on fera appel à cet objet, on lui enverra les éléments (on parle d’arguments) dont il a besoin, à savoir le nombre de titres et la valeur nominale ;
 il nous retournera une valeur ; ici, il s’agira d’une valeur numérique : le montant du capital.

Avec un langage orienté objet, le code est donc décentralisé : il comprend un code principal, qui constitue le cœur du programme, et divers objets auxquels il fait appel en cas de besoin ; il est possible de répartir ces différents éléments entre plusieurs fichiers si on le souhaite.

La programmation orientée objet offre de multiples avantages :
 elle permet d’alléger considérablement le code et de le rendre plus lisible ;
 elle en facilite la maintenance ;
 elle permet de répartir l’écriture du code entre plusieurs personnes ;
 un même objet peut être appelé par plusieurs tâches différentes sans que l’on ait besoin de réécrire le code à chaque fois.

Pour les besoins de la démonstration, on a pris un exemple simple ; mais il est aisé de concevoir des exemples plus complexes :
 supposons l’utilisation d’un logiciel pour rédiger le procès-verbal d’une assemblée générale d’approbation des comptes d’une SARL ; il devra être en mesure de déterminer si une opération intervenue en cours d’exercice est ou non une convention réglementée devant être mentionnée dans le rapport spécial prévu par l’article L 223-19 du Code de commerce ;
 un logiciel peut également avoir à calculer les droits respectifs des membres d’une indivision afin de formaliser la vente d’un bien indivis.

Le code nécessaire à cette opération est alors bien plus lourd et l’on conçoit aisément l’intérêt qu’il y a à raisonner en objet :
 le code principal procède à un simple appel de fonction ; cet appel tient en une ligne ;
 cette fonction est certes très lourde : elle retourne non plus une simple valeur numérique mais une liste - dans le premier cas, une réponse négative ou affirmative et s’il y a lieu la liste des associés ou gérants intéressés à l’opération ; dans le second la liste des indivisaires et l’étendue des droits de chacun dans l’indivision- les arguments nécessaires ayant été préalablement communiqués par l’utilisateur et éventuellement stockés dans une base de données ; mais sa lourdeur importe peu : elle n’est rédigée qu’une seule fois dans tout le programme et peut être isolée dans un fichier séparé.

De plus, tout en n’étant rédigée qu’une fois, elle pourra être appelée par de multiples opérations différentes :
 un code retournant comme information le caractère réglementé ou non d’une convention - et la liste des personnes intéressées à l’opération s’il y a lieu - peut être appelé lors de la rédaction d’un procès-verbal d’assemblée annuelle de SARL mais aussi de SCI, de SAS… ; notons qu’il faut alors transmettre en argument la forme sociale car la fonction ne retournera pas exactement la même valeur selon cette forme, les articles L 223-19, L 612-5 et L 227-10 du Code de commerce différant sensiblement ; il n’y a néanmoins pas lieu de créer autant de fonctions qu’il y a de formes sociales - une seule suffit ;
 une fonction retournant les droits respectifs des membres d’une indivision peut être appelée lors de la rédaction d’un contrat de vente mais aussi d’un acte constatant une décision collective dans une société - aux fins de détermination du mandataire appelé à exercer le droit de vote attaché à des titres indivis, etc.

1.1.2 - La rédaction orientée objet.

La rédaction de maquettes d’actes peut elle aussi - et à notre sens, doit - être orientée objet.

Il y a deux façons de concevoir les maquettes d’actes :
 elles peuvent être monolithiques : toutes les clauses et options possibles peuvent être présentes dans chaque maquette ;
 mais elles peuvent être éclatées en une multitude de fichiers : des fichiers sources, qui constituent le corps d’un acte, et des fichiers cibles.

On voit immédiatement la similitude entre cette seconde méthode et l’architecture d’un programme orienté objet : dans les deux cas, un fichier constitue le corps du programme ou de l’acte ; des fonctions ou clauses additionnelles sont logées dans des fichiers extérieurs et sont communs à plusieurs programmes ou actes qui y font appel si nécessaire.

On retrouve donc les mêmes avantages : les maquettes sont allégées et plus lisibles, leur maintenance est facilitée, etc.

Cette identité d’architecture entre le code et la bibliothèque d’actes est en fait centrale dans la perspective de la conception d’un logiciel de rédaction d’actes ; si l’on crée des maquettes d’actes en respectant cette architecture orientée objet, chacune de ces maquettes va être considérée par le code chargé de les manipuler comme un objet.

C’est ainsi par exemple qu’une clause traitant de l’apport en nature d’un fonds de commerce, très lourde, n’a aucune raison de figurer à l’intérieur de la maquette de SARL, de SAS, de SNC, d’EARL... qui ne l’utilisera que très occasionnellement. De même, rien ne justifie que le code traitant cet apport encombre le code principal traitant d’une constitution de société.

Tant la clause que le code chargé de la manipuler auront tout intérêt à être isolés dans des fichiers dédiés.

De plus, il sera assez facile de n’avoir qu’un seul fichier commun - avec évidemment un certain nombre d’options - permettant d’apporter indifféremment un fonds de commerce, une entreprise artisanale voire même une exploitation agricole ; la clause permettant un tel apport pourra en outre être insérée - si elle a été conçue par son rédacteur en pensant à cette éventualité ! - aussi bien dans une maquette de constitution de société que dans le procès-verbal d’une assemblée générale d’augmentation de capital constatant un apport en nature de fonds.

On imagine sans peine la supériorité d’une telle architecture sur celle consistant à insérer dans toutes les maquettes toutes les clauses envisageables… ce qui devient rapidement un cauchemar logistique : car ces clauses sont alors répétées à l’identique dans une multitude de fichiers et toute mise à jour doit être répétée autant de fois !

La seule difficulté de ce concept de rédaction orientée objet par rapport à un système de maquettes monolithiques est qu’il implique une logique d’assemblage de clauses. On verra qu’il n’y a là rien d’insurmontable.

1.1.3 - Apprendre les bons réflexes.

Quelques astuces de conception simples à l’intention du concepteur de maquettes d’actes seront énumérées ci-après.

De telles pratiques ne seront pas seulement utiles dans la perspective de l’utilisation de la bibliothèque d’actes par un logiciel ; car les fichiers ont également - et principalement ! - vocation à être utilisés comme modèles d’actes dans un logiciel de traitement de texte ; de la même façon que ce qui suit simplifie le travail d’un logiciel, il simplifie aussi celui d’un opérateur humain travaillant classiquement sous traitement de texte.

On ajoutera que ces pratiques ne sont pas à réserver au conseil. Elles ont aussi leur place en matière contentieuse. Même les conclusions et actes de saisine peuvent en bénéficier.

D’une façon générale : tout ce qui facilite le travail d‘un utilisateur qui se contenterait d’utiliser les maquette d’actes sous traitement de texte simplifiera aussi celui du développeur et la conception du logiciel chargé de les manipuler.

Il va de soit que la liste ci-dessous est aussi indicative qu’incomplète.

1.1.3.1 La première bonne pratique consiste évidemment, à chaque fois que l’on imagine une clause nouvelle dans le cadre d’un dossier donné, à la réaliser d’abord sous forme d’une clause-type venant enrichir la maquette de base.

1.1.3.2 Un certain nombre de blancs, dans les maquettes, auront vocation à être remplacés par le même texte ; ce sera par exemple le cas de la dénomination d’une société : il suffit, partout où ce remplacement devra être fait, non pas d’insérer un espace vide mais une expression ; exemple pour l’article énonçant la dénomination d’une société :

« ARTICLE X
La société a pour dénomination : . »

Un simple rechercher-remplacer permettra de remplacer l’expression par la dénomination dans tout le document ; à noter qu’il est très intéressant pour profiter à plein de cette méthode de réunir plusieurs documents dans un même fichier, tels que, pour reprendre l’exemple d’une constitution de société, la maquette de statuts mais aussi celles du procès-verbal d’assemblée générale constitutive et de l’annonce légale ; l’expression sera ainsi remplacée d’un bloc dans tous les documents du dossier constitutif.

1.1.3.3 Certains blancs auront vocation à être comblés manuellement et non au moyen d’expressions entre crochets ; en ce cas, peut être adoptée la pratique suivante :
 une suite de 15 underscores caractérisera un blanc devant être comblé sous traitement de texte par des caractères alphanumériques donc par du texte ;
 une suite de 5 underscores caractérisera un blanc devant être comblé par des caractères numériques donc des chiffres ;
 une suite de points (en nombre toujours multiple de 15) caractérisera un espace qui ne doit pas être comblé sous traitement de texte mais doit être laissé tel quel par le rédacteur pour accueillir du texte manuscrit.

On crée ainsi une norme compréhensible aussi bien par un opérateur humain que par un programme.

1.1.3.4 Dans les contrats, certains rédacteurs indiquent le nom des parties à de multiples reprises à l’intérieur de l’acte au motif que cela personnaliserait le document remis au client (« Monsieur X accepte », « Madame Y s’engage à »...) ; c’est une pratique à notre sens totalement contre-productive : le contrat devra être profondément remanié selon que la personne sera du sexe masculin ou féminin, ce qui est un très bon moyen de faire perdre à son assistant(e) un temps précieux qui serait mieux utilisé ailleurs… et d’en faire perdre plus tard au développeur qui devra gérer cette difficulté.

On favorisera donc toujours la solution consistant à identifier une personne par une expression neutre ; exemple pour un contrat de travail :

« Entre les Soussignés :
Monsieur X,
Ci-après l’Employeur,
Et Madame Y,
Ci-après le Salarié,
Il est convenu… (etc.). »

1.1.3.5 Pour les procès-verbaux de sociétés, les décisions peuvent être prises par un ou plusieurs associés ; afin que les clauses soient communes aux deux situations, on émettra deux recommandations :
 évoquer en cas de pluralité d’associés, non pas « les associés » mais « la collectivité des associés » ; ainsi, selon que la clause sera utilisée dans une société uni ou pluripersonnelle, le sujet sera toujours au singulier ;
 il sera dans un cas au masculin - « l’associé » - dans l’autre au féminin - « la collectivité des associés » ; un recours au participe présent permet de surmonter l’écueil.

Seul le sujet des résolutions sera modifié : le reste du texte restera inchangé.

1.1.3.6 Ne jamais utiliser de taquets de tabulation. Favoriser le recours à des tableaux.

Bannir également les fonctionnalités propres à certains logiciels - Microsoft Word en regorge, telles que celles permettant d’insérer des commentaires.

1.1.3.7 Lorsque des clauses additionnelles sont localisées dans des fichiers distincts du fichier utilisé pour la maquette de base, il peut être difficile de retrouver l’emplacement de la maquette cible…

Une solution simple consiste à insérer dans les maquettes principales des liens hypertextes pointant vers les réservoirs de clauses additionnelles précédés d’une brève invite (Exemple : « Si vous souhaitez insérer ici une clause permettant l’apport d’un fonds de commerce : cliquer ici. ») ; outre qu’il permet à l’utilisateur de rapatrier immédiatement la clause requise, le lien indiquera également à un logiciel de rédaction d’acte la localisation de la clause à rapatrier.

D’une façon générale, lorsque l’on veut attirer l’attention du rédacteur sur la possibilité d’insérer une clause additionnelle à un endroit donné, il pourra être utile de le signaler à cet endroit par une invite commençant par « Si... » ; une invite introduisant non une possible clause additionnelle mais une possible clause alternative sera quant à elle signalée par une invite de la forme « Ou, si... » ; ces invites gagneront à être mises en valeur, par exemple en les mettant en gras, souligné et italique afin de bien les distinguer du texte courant.

L’intérêt d’invites ainsi conçues, outre qu’elles auront pour un rédacteur humain un caractère informatif, est qu’elles rempliront aussi une fonction de balise pour un logiciel ; ainsi, quand il détectera un « S » majuscule, gras souligné et italique, il identifiera un point d’insertion d’une possible clause additionnelle.

1.2 - Penser aussi comme un juriste.

Si le juriste doit penser comme un développeur, il est utile de rappeler que le développeur doit quant à lui parfois penser comme un juriste.

Cependant, dans le processus de développement d’applications de rédaction d’actes, l’intervention du juriste précède habituellement celle du développeur.

Il est donc de la responsabilité du professionnel du droit d’anticiper les problèmes d’ordre juridique qui pourront se poser au développeur et d’attirer son attention sur lesdits problèmes - et non l’inverse ; cette responsabilité est trop largement ignorée.

Supposons, à titre d’exemple, une boîte de dialogue permettant à l’utilisateur de saisir l’état-civil d’une personne physique.

Diverses informations seront requises ; il en sera ainsi, notamment :
 de la situation matrimoniale de cette personne,
 et, si elle est mariée, de la date du mariage et de son régime matrimonial - ces informations étant indispensables pour rédiger nombre d’actes.

Afin d’offrir à l’utilisateur un confort de travail optimal, il importe qu’il n’ait pas à saisir lui même le régime matrimonial ; l’interface du logiciel comprendra donc une liste déroulante dans laquelle il aura simplement à sélectionner le régime correspondant dans une liste préétablie.

Or, on le sait, la liste des régimes autorisés a été profondément modifiée par la réforme du droit des régimes matrimoniaux entrée en vigueur le 1er février 1966.

Cela signifie donc :
 que la saisie du régime matrimonial doit être impossible tant que la date du mariage n’est pas saisie ;
 que la liste des régimes possibles ne sera visible dans la liste déroulante qu’une fois cette date communiquée par l’utilisateur et que le contenu de la liste - donc les choix possibles - sera fonction de cette date.

En Python - langage informatique qui sera présenté dans la seconde partie - la génération de la liste des régimes matrimoniaux possibles en fonction de la date du mariage peut être codée comme suit :

if self.TxtDateMarPACS.DetectDate() < date(1966, 2, 1):# Mariés avant le 1er février 1966
   ListeRegimeMat = [u"Régime légal (communauté de meubles et acquêts)",
                     u"Communauté d'acquêts (sur option)",
                     u"Communauté d'acquêts (par contrat)",
                     u"Séparation des biens (sur option)",
                     u"Séparation des biens (par contrat)",
                     u"Participation aux acquêts",
                     u"Communauté intégrale",
                     u"Régime sans communauté",
                     u"Régime dotal"]
   # Rappel : le régime sans communauté est interdit depuis 1966.
   # Mais les personnes antérieurement mariées sous ce régime
   # ont pu soit le conserver,
   # soit opter pour la séparation de biens (art 17).
else:# Mariés à compter du 1er février 1966
   ListeRegimeMat = [u"Régime légal (communauté d'acquêts)",
                     u"Séparation des biens",
                     u"Participation aux acquêts",
                     u"Communauté intégrale"]

Rappelons que l’adoption du régime sans communauté était selon la plupart des commentateurs encore possible jusqu’au 30 juin 1986 inclus ; mais faute d’unanimité sur ce point, personne ne l’adopta plus en pratique à partir de l’entrée en vigueur de la loi de 1965. Pour cette raison, il apparaît inutile de le mentionner dans la liste des régimes possibles si les époux se sont mariés après le 31 janvier 1966.

On se dispensera par contre de communiquer au développeur la liste des régimes matrimoniaux pouvant être choisis par des personnes mariées avant les réformes antérieures à celle de 1965, la dernière datant de 1884 : il sera en effet assez rare que l’utilisateur soit amené à rédiger des actes pour le compte de clients mariés depuis 140 ans...

Dans cet exemple, un minimum de connaissances du droit des régimes matrimoniaux et de l‘évolution de la matière aura une incidence directe sur la conception de l’interface graphique du logiciel. Cela n’est certes pas de la responsabilité du développeur mais du juriste ; c’est donc à ce dernier d’anticiper et d’en aviser le développeur et non l’inverse.

2 - Le code, moteur du programme.

2.1 - Maquettes intégrées versus maquettes séparées.

Lorsqu’un logiciel doit manipuler des maquettes d’actes, il y a deux façons d’associer ces maquettes au code :
 le texte des modèles d’actes peut être inséré dans le code ;
 le texte des modèles d’actes peut être contenu dans des fichiers utilisables sous traitement de texte.

La première méthode a longtemps été favorisée. Elle présente pourtant un inconvénient en ce sens que les maquettes d’actes conçues sous traitement de texte par un juriste pour son usage personnel ne sont pas exploitées telles quelles par le logiciel ; tout existe donc en double : une version pour le logiciel et une version pour utilisation sous traitement de texte ; et toute modification apportée par le juriste à sa bibliothèque d’acte, même une simple correction de faute d’orthographe, doit être signalée aux développeurs pour que le code soit également modifié...

La seconde n’a pas ce défaut mais a d’autres inconvénients liés notamment à l’existence sur le marché des suites bureautiques d’un monopole de fait : celui de Microsoft Word, le logiciel de traitement de texte de la suite Microsoft Office.

Le plus notable était que le code des fichiers utilisés par Word - comprendre : les fichiers doc - n’était ni libre ni ouvert ; les spécifications du format de fichier n’étant pas accessibles au public, il était impossible par programmation de lire directement le contenu de ces fichiers - et encore moins de les modifier.

La seule façon de contourner cet écueil consistait non pas à modifier le fichier doc stricto sensu mais à envoyer des instructions au logiciel Microsoft Word - en utilisant le protocole Object Linking and Embedding (OLE), technologie propriétaire de Microsoft - afin qu’il modifie un fichier doc, les instructions en ce sens étant rédigées dans le langage Visual Basic for Applications (VBA), édité par... Microsoft.

Autant dire que cette solution n’était applicable que sous Windows, imposait que le logiciel Word soit installé sur la machine, imposait le respect de licences contraignantes et coûteuses dans l’optique de la diffusion commerciale d’un logiciel de rédaction d’actes utilisant ces technologies et, d’une façon générale, plaçait les acteurs de la Legaltech et les utilisateurs dans une situation de dépendance vis-à-vis d’un éditeur unique.

Plus grave : Microsoft ayant la fâcheuse habitude, à l’occasion du lancement de nouvelles versions de la suite Office, de modifier les spécifications du format de fichier doc - de façon occulte, ces spécifications n’étant pas publiques - la pérennité d’un logiciel utilisant ces technologies n’était pas assurée.

La situation a radicalement changé avec l’irruption de nouveaux formats de fichiers bureautiques reposant sur le métalangage XML.

Deux formats de fichiers bureautiques ont été ainsi imaginés, tous deux agréés par l’ISO :
 le format OpenDocument, par l’OASIS (Organization for the Advancement of Structured Information Standards), consortium qui travaille pour la standardisation de formats de fichiers ouverts et comprend des entreprises et organisations telles qu’IBM, Intel, Airbus, Google, Boeing, des éditeurs et universités, etc. (ISO/CEI 26300) ;
 le format Office Open XML, par Microsoft en réaction contre la création du précédent (ISO/CEI 29500).

Deux normes existent donc - une anomalie qui a suscité beaucoup de controverses. Les développements ci-dessous se réfèrent au seul format OpenDocument.

Ce format est notamment celui utilisé nativement par la suite bureautique LibreOffice.

Un fichier de traitement de texte à la norme OpenDocument porte l’extension odt (OpenDocument Text).

Pour comprendre comment est conçu un fichier odt, il suffit d’examiner le code d’un tel fichier - créé par exemple sous LibreOffice Writer – ce qui est possible puisque le format est libre et ouvert :
 dans l’explorateur de fichiers d’un ordinateur, identifions un fichier odt ;
 si l’on modifie cette extension en remplaçant « odt » par « zip », on obtient une archive zip que n’importe quel logiciel d’archivage pourra décompresser [1] ;

Le résultat après décompression est un dossier contenant notamment plusieurs fichiers portant l’extension xml.

Fondamentalement, un fichier OpenDocument n’est donc qu’une archive zip contenant en clair - et non plus cryptées - toutes les informations, sous forme de fichiers xml, dont le logiciel de traitement de texte a besoin pour afficher le document.

Le plus important - pour nous - de ces fichiers est le fichier nommé « content.xml » ; comme son nom l’indique, c’est là que sont stockées en langage XML toutes les données relatives au contenu d’un fichier OpenDocument - c’est à dire, littéralement, ce qui apparaît à l’écran de l’utilisateur.

Pour nous initier au XML, supposons un fichier odt contenant le paragraphe suivant : « Article 1er ».

Si l’on décompresse ce fichier et que l’on inspecte le fichier content.xml (par défaut, un double clic sur un fichier xml ouvrira un onglet dans le navigateur web de l’ordinateur ; c’est dans cet onglet que s’affichera le contenu du fichier), ce paragraphe, en XML, apparaîtra ainsi (seule un petite partie du fichier est reproduite !) :

-<office:body>
-<office:text text:use-soft-page-breaks="true">
   <office:forms form:automatic-focus="false" form:apply-design-mode="false"/>
 +<text:sequence-decls></text:sequence-decls>
   <text:p text:style-name="P54">Article 1er</text:p>
  </office:text>
-</office:body>

Un humain entraîné apprend rapidement à déchiffrer le XML :

 le fichier content.xml comprend plusieurs sections ; l’une d’elles, placée en début de fichier (et qui n’est pas reproduite ci-dessus), définit les styles de paragraphes (la police utilisée, la fonte…) et leur attribue des noms : P1, P2, etc. 

 la section « office:body » placée en fin de fichier comprend le corps du document ; dans cette section, une sous-section « office:text » comprend le texte du document ; et dans cette sous-section se trouvent des sections « text:p » qui correspondent aux paragraphes ; on voit ici la ligne correspondant à notre paragraphe « Article 1 » auquel est appliqué le style P54 ;

 toute ligne dans un code xml commence par une balise entrante et une balise fermante ; une balise fermante est identique à la balise ouvrante correspondante si ce n’est qu’elle comprend en plus le caractère « / » : ainsi, une balise « /text:p » informe le logiciel de traitement de texte de la fin du paragraphe… donc d’un retour à la ligne.

Le code xml se présente donc sous la forme d’une arborescence (« tree ») comprenant de multiples nœuds (« nodes ») ; la plupart des langages informatiques sont capables de parcourir le code d’un fichier xml et de le modifier.

Il devient donc possible de modifier directement par programmation le contenu d’un fichier de traitement de texte : il n’est même pas nécessaire qu’un logiciel de traitement de texte soit installé. De plus, la solution devient indépendante du système d’exploitation : si l’on choisit de développer son logiciel en un langage disponible pour plusieurs systèmes (ce qui est le cas de la plupart des langages interprétés), le code fonctionnera indifféremment sous Windows, GNU/Linux ou MacOs.

A l’usage, on voit donc qu’il n’y a aujourd’hui absolument plus de justification à insérer le texte des maquettes d’actes au code ou à utiliser des formats de fichiers bureautiques propriétaires ; le recours par les formats de fichiers bureautiques actuels au XML doit frapper d’obsolescence ces pratiques qui constituent un frein au développement et contribuent à en écarter les professionnels du droit.

2.2 - Codons.

2.2.1 - Le choix du langage : compilé versus interprété.

Un ordinateur ne comprend que le langage binaire, composé de 1 et de 0.

Il serait impossible à un humain d’écrire un tel code. Les langages informatiques utilisent donc des opérateurs mathématiques (« + », « - », « = »…) et des mots-clés d’origine en général anglo-saxonne (if, or, and, else...) nous permettant de donner des instructions à la machine ; mais pour que celle-ci les comprennent et puisse les exécuter, ce code doit lui être traduit.

Deux catégories de langages existent :
 les langages compilés (C, C++, Pascal...) sont les plus anciens ; une fois le code écrit, il est traduit par un logiciel spécial appelé compilateur, qui générera un code binaire ; lorsque la compilation est terminée, il est possible de lancer l’exécution de ce code binaire sur un ordinateur ;

 les langages interprétés (Java, Python...) ne nécessitent pas de compilation ; le code est immédiatement exécuté ; cependant, comme il n’est pas en tant que tel compréhensible par l’ordinateur, il est converti en langage machine durant l’exécution, en temps réel, par un logiciel appelé interpréteur.

Le code compilé est le plus performant car immédiatement compréhensible par la machine ; mais la durée du développement - et donc son coût - est élevée car tout code une fois rédigé doit être compilé avant de pouvoir être testé. Ce type de langage est donc réservé aux applications dont le marché potentiel permet d’absorber un coût de développement important et lorsque la vitesse d’exécution et l’optimisation de la consommation des ressources sont primordiales (les jeux vidéo en 3D en temps réel sont un bon exemple).

Le code interprété requiert plus de puissance et est plus lent ; par contre, il permet de développer bien plus vite car un code fraîchement écrit peut être immédiatement testé. Les langages interprétés sont parfaitement adaptés pour concevoir des applications ayant pour but l’automatisation de tâches et où la performance importe peu ; ils conviennent donc très bien aux besoins des professionnels du droit.

2.2.2 - L’exemple de Python.

Le choix d’un langage est toujours délicat ; les développements qui suivent reposent sur l’utilisation du Python mais d’autres langages pourront tout aussi valablement être envisagés.

Parmi les langages interprétés, au vu des besoins des juristes, le Python a certains atouts :
 il est libre, gratuit, disponible sous de nombreux systèmes d’exploitation ;
 il est très simple d’accès : un profane peut en maîtriser les fondements en quelques soirées - le Python est d’ailleurs très utilisé pour enseigner la programmation ;
 ces caractéristiques permettent de développer rapidement donc à moindre coût - il est à ce titre énormément employé pour développer des applications maison tant en entreprise que par des administrations ;
 du fait de sa popularité, de nombreuses bibliothèques additionnelles existent qui permettent d’ajouter au langage des fonctionnalités supplémentaires.

A titre d’illustration, voici un script Python - pour Python 2 [2] - complet permettant de remplacer dans une maquette vierge de statuts de société l’expression par la dénomination sociale entrée par l’utilisateur ; ce code va procéder au remplacement dans tout le fichier, à chaque fois qu’il va y trouver l’expression .

# !/usr/bin python2.6
# -*- coding: iso-8859-15 -*-

from zipfile import ZipFile, ZIP_DEFLATED
from StringIO import StringIO
from xml.etree import ElementTree

# Conservation des namespaces
[...]

def Constitution(projet, nouveauDocument, maquette):
# projet est le nom du dossier choisi par l’utilisateur, nouveauDocument le nom du fichier à générer, maquette le fichier de maquette d’acte qui va être utilisé pour créer ce fichier.

   outzip = ZipFile(nouveauDocument, "w", ZIP_DEFLATED)
   inzip = ZipFile(maquette, "r", ZIP_DEFLATED)
   content = ElementTree.ElementTree(ElementTree.fromstring(inzip.read('content.xml')))

   root = content.getroot()# Objet Element valide

   NS_OFFICE = '{urn:oasis:names:tc:opendocument:xmlns:office:1.0}'
   tree = content.find(NS_OFFICE + 'body')

   for e in tree:
       if e.tag == '{urn:oasis:names:tc:opendocument:xmlns:office:1.0}text':
           tree = e
       
   iterateur = tree.getiterator()#[1:]
   # Ce suffixe élude l'Element racine "body"
       
   donnees = projet.RecupDonnees('PanneauCarSoc')
   # Récupère les informations, affichées dans l’interface graphique du logiciel, concernant la société

   remplace(iterateur, code='<den>', expression=donnees['nom'])

   # Génération du fichier de sortie
   for f in inzip.infolist():
       if f.filename == 'content.xml':
           s = StringIO()
           content.write(s)
           outzip.writestr('content.xml', s.getvalue())
       else:
           outzip.writestr(f, inzip.read(f.filename))
   inzip.close()
   outzip.close()

def remplace(iterateur, code, expression):
   for elem in iterateur:
       text = gettext(elem)
       if code in text:
           elem.text = text.replace(code, expression)

def gettext(elem):
   text = elem.text or u""
   for e in elem:
       text += gettext(e)
       if e.tail:
           text += e.tail
   return text

Les instructions varient selon qu’il s’agira de remplir un blanc, d’ajouter du texte ou d‘en supprimer mais le principe sera toujours le même [3]
 le code génère un nouveau fichier OpenDocument en créant sur le disque dur de l’utilisateur une copie d’une maquette préexistante ;
 il le décompresse puis inspecte son fichier content.xml en y procédant aux modifications, suppressions et adjonctions requises ;
 il sauvegarde le résultat une fois que toutes ces modifications, suppressions et adjonctions ont été faites.

L’un des défauts d’ElementTree - la bibliothèque fournie avec le langage Python pour inspecter et modifier le code d’un fichier xml - est qu’il ne peut inspecter que des nœuds enfants, non les nœuds parents : cela signifie que toute instruction - le remplacement d’une expression par une autre, le remplissage d’un blanc, la suppression ou l’adjonction d’un paragraphe, etc. - se traduit par une inspection de la totalité de l’aborescence [4] ! Et la génération d’un seul acte juridique peut nécessiter des milliers d’instructions de ce genre…

Cette difficulté doit cependant être relativisée ; sur un PC doté d’un processeur Intel Core i3 ou équivalent doté de 4 Go de RAM, la génération de documents mêmes très complexes ne prend que rarement plus d’une dizaine de secondes.

Cet exemple de code illustre deux points cruciaux :
 il ne fonctionnera qu’à la condition que la dénomination sociale, dans la maquette d’acte, soit signalée par l’expression  ; toutes les maquettes (statuts de société, PV d’AG, couvertures de documents reliés, etc.) qui auront vocation à être manipulée par le logiciel doivent suivre cette règle ;
 il ne faut surtout pas que certaines maquettes utilisent l’expression pour autre chose que la dénomination sociale !

Supposons pour illustrer cette dernière erreur ainsi que le code ci-dessus ait à générer un acte de cession de parts sociales au profit d’une société ; si le créateur de la maquette d’acte de cession a utilisé l’expression pour désigner non pas la dénomination sociale de la société dont des titres sont cédées mais un acquéreur personne morale, le résultat pourrait être cocasse… mais désastreux.

Il est à noter que la manipulation peut porter sur le contenu du document stricto sensu mais aussi sur ses forme et présentation en agissant sur la partie du fichier content.xml qui définit les styles de paragraphe - ou sur le contenu d’un autre fichier, nommé styles.xml, qui définit les styles de page ; de même, il est possible de créer et compléter des tableaux - par exemple d’apports en nature faits à une société ou la liste de parcelles louées à bail rural.

Les possibilités sont donc pratiquement infinies et l’on peut réaliser un document dont la présentation ne requiert ensuite aucun travail de mise en forme - long, pénible et de surcroît intellectuellement dépourvu de tout intérêt pour l’assistant(e) - qu’imposent encore certaines applications générant des fichiers rtf ou doc.

Conclusion.

Il n’était évidemment possible que d’effleurer le sujet ; les spécificités du format OpenDocument telles qu’elles furent communiquées à l’ISO à elles seules font plus de 700 pages… et celles du format Office Open XML plus de 7.000.

Une question cependant subsiste : le juriste doit-il devenir lui-même un programmeur ?

L’un des intervenants à l’occasion de l’édition 2018 du Village de la Legaltech avait affirmé que cela devait être exclu.

Votre serviteur est d’une opinion résolument contraire ; imagine-t-on revenir à une époque où seuls les moines comprenaient le latin ? Certes non ; et les langages actuels offrent aux professionnels du droit le moyen d’apprendre à développer eux-mêmes sans investissement personnel excessif.

L’obstacle principal est en fait le temps disponible - non pour l’apprentissage, qui reste accessible, mais pour développer l’application.

A défaut de faire eux-mêmes ce travail de développement, les juristes - et plus précisément les avocats - auront néanmoins tout avantage à comprendre les rudiments du ou des langage(s) utilisé(s) pour sa réalisation.

Maîtriser les possibilités mais aussi les contraintes de la programmation permettra aux professionnels du droit de mieux collaborer avec les développeurs et de contribuer à la conception de produits de meilleure qualité.

Cela leur permettra aussi de prendre une place plus importante dans la Legaltech - et, éventuellement, d’en reprendre le contrôle.

Vincent BILLETTE K&B AVOCATS ASSOCIES Avocat Barreau des Deux-Sèvres