Dans ma société je rédige de nombreux contrats de développement ou de consulting. J'ai remarqué récemment le lien entre ce travail et la programmation. Tout me fait penser qu'un contrat rédigé par un programmeur logiciel doit forcément être de bonne qualité.
Tout est une question de robustesse
En quoi consiste la programmation ? Basiquement, rédiger un programme informatique consiste à faire faire une tâche à une machine. Cette tâche peut être de n'importe quelle nature : un algorithme de tri, une série de calculs, afficher un texte, calculer la position GPS la plus proche de l'utilisateur, etc. Le but de votre programme est qu'il soit robuste. Cela signifie qu'il ne doit pas planter.
Dans l'enseignement de l'informatique, pour illustrer un plantage (bug), on donne souvent l'exemple d'une division par zéro : Si votre programme venait à faire une division par zéro, il planterait (car cette opération n'est pas possible en mathématique).
Ainsi, rendre un programme robuste consiste à le protéger des bugs qui pourraient survenir. On croit souvent que le travail de programmeur consiste à rédiger du code et ajouter de nouvelles fonctionnalités sans arrêt. C'est faux : avant d'écrire la moindre ligne, il est primordial de concevoir son code. Cette étape consiste à imaginer comment réaliser la tâche mais également à imaginer tous les cas possibles qui pourraient survenir, pour être sûr de tous les gérer. Vient ensuite la programmation en tant que telle (la rédaction du code). Puis enfin, et c'est une étape très importante, les tests. Ceux-ci vont permettre de vérifier que tout fonctionne convenablement.
Le travail de programmeur consiste donc en majorité à réfléchir, concevoir, tester, essayer, corriger, vérifier, corriger encore. Tout ça dans le seul but d'avoir un programme qui marche dans tous les cas.
Pour illustrer cela, prenons un exemple concret. Imaginez devoir réaliser le traitement d'un formulaire sur le web. Vous avez déjà tous utilisé des formulaires, ce sont ces champs de saisie que vous remplissez puis validez pour faire une action : s'inscrire sur un forum, passer une commande, changer son statut sur son réseau social préféré, etc.
Dans notre exemple, prenons un formulaire pour réaliser un virement bancaire. Imaginez tous les cas possibles d'erreur : le champ "montant" est resté vide, ou il a une valeur négative, ou un texte ("huit CHF") ; l'IBAN n'a pas assez de caractères, ou trop ; votre nom contient des caractères non supportés, etc. Ce sont tous ces cas que le programmeur doit gérer pour être certain que si le formulaire est validé, le virement bancaire pourra avoir lieu, sans planter.
Un bug est, dans la grande majorité des cas, la cause de facteurs externes au programme : très souvent directement les interactions de l'utilisateur (les champs saisis dans le formulaire dans notre exemple), mais également des données externes au programme (paramètres d'entrées, état de la mémoire, etc.).
Le programmeur doit définir un cadre dans lequel son programme pourra fonctionner. Puis en informer l'utilisateur au cas où celui-ci essayerait d'en sortir. Il vérifie que son code est logique, qu'il fait la tâche qu'on s'attend qu'il fasse. Le travail du programmeur est de concevoir et réaliser un programme qui réponde aux besoins des utilisateurs, sans surprise et sans plantage afin qu'ils puissent l'utiliser en toute confiance. C'est une véritable lutte entre la logique implacable de la machine et tous les cas possibles induits par l'utilisation même du programme par des utilisateurs.
Ce n'est pas évident, mais quel beau métier ! J'y reviendrai certainement dans un futur article.
En rédigeant cette première partie, je me suis souvenu d'un client qui m'avait demandé pourquoi notre équipe ne codait pas directement sans bug ... Bonne question !
Quel est le lien avec un contrat ?
À quoi sert un contrat ? Peu importe sa nature, son domaine d'application et ce qu'il couvre, son but est de fixer un cadre. Il permet d'éviter les mauvaises surprises pour les parties prenantes, de s'assurer que tout soit réalisé comme prévu et de gérer les imprévus.
Dans mon activité professionnelle je rédige beaucoup de contrats. Principalement pour des projets de développement, mais également du consulting ou pour des abonnements (frais récurrents). J'ai remarqué récemment que l'écriture d'un contrat s'apparente à l'écriture d'un programme.
Je commence par définir le cadre d'application du contrat en expliquant des termes techniques pour qu'ils soient compris du client et assurent la base commune ( définition des variables du programme).
Je détaille ensuite comment doit fonctionner le produit final (une fonctionnalité dans un logiciel, un projet, etc.). J'ai tendance à être très précis pour ce genre d'élément afin de fixer clairement comment doit être réalisé le projet ( code source du programme).
Je fixe ensuite des objectifs quantifiables afin de s'assurer que le produit rendu corresponde à ce que le client a besoin ( tests de sortie).
Puis j'ajoute l'ensemble des conditions du projet ( tests dans le code).
Tout ceux qui ont déjà eu à rédiger des contrats, à réaliser un projet, puis à confronter le rendu final au client, savent qu'il est vite arrivé d'oublier un cas que le client attendait mais qui n'était pas exprimé dans le contrat. On se retrouve alors dans une situation délicate : qui doit payer pour quelque chose qui n'était pas clairement exprimée dans le contrat, mais qui n'était pas non plus clairement isolé ?
Mon objectif est de réaliser un projet dans un cadre que je fixe (en accord avec les besoins de mon client, bien sûr). Je veux qu'il se déroule comme je l'ai conçu et qu'il ne puisse pas échouer. Au fil des contrats que j'ai rédigés, j'ai appris qu'il est primordial de ne laisser la place à aucun doute, à aucune possibilité de mal comprendre quelque chose ou d'en ignorer d'autres. En d'autres termes, gérer tous les cas possibles induits par le client. Cela ressemble fortement à un programme, non ?
Rédiger un contrat c'est s'assurer que son code / son projet est robuste ; qu'il résiste à tous les paramètres d'entrées / imprévus du projet ; qu'il corresponde aux besoins de l'utilisateur / du client sans surprise et sans illogique ; qu'il résiste à toutes les possibilités de l'utilisateur / du client, même celles qui n'étaient pas prévues.
Un programmeur est-il un bon rédacteur de contrat ?
De manière générale, la construction d'un programme et d'un contrat sont identiques. Il faut certainement avoir rédigé à la fois du code et des contrats pour se rendre compte de cela. Mais je suis persuadé que la satisfaction d'un contrat bien réalisé est la même qu'un logiciel robuste. Et ce pour le programmeur et pour l'utilisateur / le client. Les deux trouvent leur compte : le premier est rassuré que son programme fonctionne bien / son contrat se déroulera bien quoi qu'il arrive ; le deuxième est rassuré d'avoir à disposition un logiciel / un projet qui couvre les besoins qu'il attendait.
Je ne peux bien sûr pas affirmer que tous les programmeurs rédigeront de bons contrats. Je pense qu'il est nécessaire d'avoir la conscience de la relation client et des notions commerciales et légales, ce que n'aura pas forcément un programmeur.
Mais force est de constater qu'avec ma formation et mon expérience en ingénierie logicielle, je rédige des contrats très robustes. J'en ai parlé à mon associé qui a suivi pratiquement la même formation que moi mais qui s'est tourné ensuite vers le droit, et il a remarqué les mêmes similitudes sur l'ensemble des contrats, pas seulement ceux touchant à l'informatique.
Si vous êtes vous-même ingénieur en développement logiciel et que vous devez rédiger des contrats pour des clients, pensez-y. Voyez tout ça comme un ensemble de variables, de conditions de vérification, de paramètres d'entrées et de tests. Et réfléchissez à tous les cas naïfs ou sournois qui pourraient survenir dans le cadre d'un projet. Vous remarquerez que vous avez certainement déjà dû réaliser un algorithme plus compliqué avec des facteurs tout aussi complexes.