Ce qui vous appartient quand le système est prêt : code, données et dépendance vis-à-vis du développeur

Le système est remis, la facture est payée, et six mois plus tard l’entreprise décide de changer de développeur, et c’est précisément à ce moment-là que se pose la question que personne jusqu’alors n’avait jugée urgente : à qui appartient ce pour quoi l’on a payé. La réponse, en France, surprend presque tous ceux qui l’entendent pour la première fois, car le paiement de la réalisation ne donne pas, à lui seul, au commanditaire les droits patrimoniaux sur le programme d’ordinateur créé, et ce n’est pas une subtilité juridique, mais le régime par défaut, qui s’applique chaque fois que le contrat n’a rien inscrit d’autre.

Cet article porte sur ce qui reste entre vos mains après la remise, et ce n’est pas la même question que celle que nous avons déjà examinée en comparant un produit du marché et un logiciel sur mesure. Là, il s’agissait de ce qu’il faut choisir ; ici, il s’agit de ce que vous tenez entre les mains une fois le choix fait et le système en service. La réponse se partage en trois : le code et les droits sur ce code, les données avec le lieu où elles sont conservées, et la dépendance vis-à-vis des personnes qui connaissent le système.

L’auteur est toujours une personne, pas une société

Au sens du Code de la propriété intellectuelle, l’auteur est la personne physique dont l’activité créatrice a produit l’œuvre, et cela signifie qu’une société n’est pas l’auteur : les auteurs sont les programmeurs, les designers et les rédacteurs qui ont travaillé sur le système. Les programmes d’ordinateur sont protégés comme des œuvres littéraires, comme dans la directive 2009/24/CE de l’Union européenne, et le droit d’auteur naît au moment où l’œuvre est créée, même inachevée, sans enregistrement et sans mention.

Le droit d’auteur se partage en deux parts, que le code français nomme le droit moral et les droits patrimoniaux, et dans la pratique c’est le partage le plus important de tout ce sujet, parce que seule l’une des deux peut parvenir à l’entreprise. La part patrimoniale est celle que l’on peut céder, et, pour un programme d’ordinateur, elle permet de le reproduire, de le traduire, de l’adapter, de l’arranger ou de le modifier autrement, de le mettre sur le marché, y compris par la location, et de reproduire le résultat de ces transformations. Le droit moral reste attaché à l’auteur : il est perpétuel, inaliénable et imprescriptible, et c’est précisément pour cela qu’aucun contrat ne peut inscrire que l’entreprise devient l’auteur.

Il existe encore une frontière que l’on remarque rarement, et elle peut se révéler coûteuse. L’article L. 113-9, qui dévolue les droits patrimoniaux à l’employeur, ne parle que des logiciels et de leur documentation, alors que pour tout le reste de ce que le projet produit, à savoir le design, les textes et les consignes qui ne sont pas cette documentation, c’est l’alinéa 3 de l’article L. 111-1 qui s’applique, et le régime par défaut y est autre : le contrat de travail n’emporte pas dérogation à la jouissance du droit d’auteur, donc ces droits restent chez l’auteur tant qu’une cession écrite, dans les conditions de l’article L. 131-3, ne les a pas transmis. Concrètement, cela signifie que, dans un même projet, deux choses créées peuvent avoir deux titulaires différents, et qu’un contrat qui ne parle que du logiciel peut laisser le design à l’extérieur.

De là suivent les premières conséquences pratiques, qu’il vaut la peine de comprendre avant tout le reste : quand une entreprise commande un système à une agence, la chaîne des droits a au moins deux maillons, parce que d’abord les programmeurs sont auteurs, ensuite l’agence a ou n’a pas obtenu d’eux la part patrimoniale, et seulement alors l’agence peut vous céder quelque chose. Si un maillon manque, l’agence promet plus que ce qui lui appartient, et on ne s’en aperçoit que lorsque quelqu’un commence à vérifier.

Salarié et commande sont deux régimes par défaut distincts

Ici se trouve le cœur de l’article, et c’est l’endroit où l’intuition mène dans la mauvaise direction. L’article L. 113-9 du Code de la propriété intellectuelle dispose que, sauf stipulations contraires, les droits patrimoniaux sur les logiciels et leur documentation créés par un ou plusieurs employés dans l’exercice de leurs fonctions ou d’après les instructions de leur employeur sont dévolus à l’employeur, qui est seul habilité à les exercer. C’est la réponse française à l’article 2, paragraphe 3, de la directive 2009/24/CE, et elle ne concerne que la relation de travail et que les logiciels — avec, en France, leur documentation.

Pour un contrat de commande, le régime par défaut est l’inverse, et c’est précisément pour cela qu’il ne faut pas confondre les deux cas : l’alinéa 3 de l’article L. 111-1 dispose que l’existence ou la conclusion d’un contrat de louage d’ouvrage ou de service par l’auteur d’une œuvre de l’esprit n’emporte pas dérogation à la jouissance du droit d’auteur, sous réserve des exceptions prévues par le code. Le contrat d’entreprise, au sens des articles 1710 et 1787 du Code civil, ne dit rien du tout sur le droit d’auteur, parce qu’il régit l’exécution du travail et sa livraison, non la circulation des droits.

Mettez les deux bout à bout, et vous obtenez la situation dans laquelle une entreprise typique se trouve, souvent sans le savoir : le client commande un système à une agence ; les programmeurs sont salariés de l’agence, donc l’article L. 113-9 dévolue la part patrimoniale à l’agence ; le contrat entre le client et l’agence est un contrat d’entreprise, qui ne la transmet pas plus loin. Il en résulte que le client a payé le résultat et reçu le résultat, mais que la part patrimoniale est restée chez l’agence, et que la seule chose que le client détient est une licence de droit d’auteur implicite, floue, d’utiliser le système pour la finalité pour laquelle il a été commandé.

C’est une idée reçue répandue que les droits sur un programme d’ordinateur appartiendraient à la personne qui en a commandé et payé la réalisation, et que le Code de la propriété intellectuelle prévoirait une dévolution automatique au commanditaire. Il n’en prévoit pas. L’alinéa 3 de l’article L. 111-1 dit le contraire, et le contenu d’une licence seulement implicite reste flou. Parce que c’est le texte de la loi, il vaut la peine de le lire avec le contrat, et dans ce cas le texte confirme précisément cette lecture.

Recevoir les fichiers n’est pas recevoir les droits

La deuxième hypothèse qui ne résiste pas à l’examen est que la réception du code déciderait de quoi que ce soit, mais l’article L. 111-3 du Code de la propriété intellectuelle dispose que la propriété incorporelle est indépendante de la propriété de l’objet matériel, et que l’acquéreur de cet objet n’est investi, du fait de cette acquisition, d’aucun des droits prévus par le code. En pratique, cela signifie qu’une archive contenant tout le code source, l’accès au dépôt et même une documentation complète ne sont toujours pas la même chose que le droit d’utiliser ce code, de le transformer et de le passer à un autre développeur.

Cela fonctionne aussi dans l’autre sens, et ce côté-là est moins connu, parce qu’une entreprise peut avoir obtenu les droits patrimoniaux par un contrat bien rédigé, et n’avoir pourtant jamais reçu le code source, si le contrat n’inscrivait pas à part l’obligation de le remettre. Une autorisation sans le fichier est aussi inutilisable qu’un fichier sans l’autorisation, donc le contrat a besoin des deux, et ce sont deux points autonomes, non un point qui contiendrait l’autre de lui-même.

Quand les droits sont cédés correctement, la loi exige une certaine précision, et ce n’est pas une formalité, parce que le code permet de céder la part patrimoniale ou de la licencier, en indiquant dans l’acte le lieu et la durée, mais il n’y a pas, en France, de règle qui, si le territoire n’est pas mentionné, tiendrait la cession pour limitée à l’État où le contrat a été conclu. L’article L. 131-3 subordonne la transmission à la condition que chacun des droits cédés fasse l’objet d’une mention distincte et que le domaine d’exploitation soit délimité quant à son étendue et à sa destination, quant au lieu et quant à la durée. Pour une entreprise qui opère dans plusieurs pays, ou qui prévoit de le faire, c’est une raison directe d’inscrire le territoire, et une formule qui ne vise qu’un mode d’exploitation n’ouvre pas les autres.

Il y a encore une surprise qui attend l’entreprise qui vit avec une licence implicite et ne l’a jamais mise par écrit. Le Code de la propriété intellectuelle ne prévoit pas qu’une licence de droit d’auteur non limitée dans le temps puisse être résiliée moyennant un préavis de six mois, ni qu’une renonciation à cette faculté serait nulle. Une entreprise dont le seul fondement d’utilisation du système est un accord non écrit ne vit donc pas avec un préavis légal de six mois : elle vit avec l’incertitude de ce que cette licence implicite lui donne réellement, et elle ne peut pas s’en tirer par une clause qui prétendrait régler ce que l’acte n’a jamais délimité.

Le droit moral, et ce qu’il n’interdit pas

Le droit moral comprend le droit au respect du nom, de la qualité d’auteur et de l’œuvre, ainsi que, dans le catalogue français, le droit de divulgation et le droit de repentir ou de retrait, et tout cela reste attaché à l’auteur, parce qu’aucun de ces éléments n’est cessible à une autre personne. Pour une entreprise qui a commandé un système, cela sonne d’abord comme une menace, parce que l’impression se forme qu’un ancien développeur pourrait, à un moment, exiger l’arrêt du système.

Dans la pratique, ce n’est pas ainsi, et la raison n’est pas un amendement de 2023 : l’article L. 121-7, dans le code depuis 1994, écarte ce risque pour les logiciels. Sauf stipulation plus favorable à l’auteur, l’auteur d’un logiciel ne peut pas s’opposer à la modification du logiciel par le cessionnaire des droits visés au 2° de l’article L. 122-6, lorsqu’elle n’est préjudiciable ni à son honneur ni à sa réputation, et il ne peut pas exercer son droit de repentir ou de retrait. Cela signifie qu’un ancien programmeur ne peut arrêter ni la maintenance ordinaire, ni une réécriture, et c’était précisément la part du droit moral qui aurait été dangereuse pour l’entreprise.

Dans le même ordre d’idées, il existe une autre règle favorable à l’entreprise et qu’il vaut la peine de connaître, parce que sinon on peut l’attendre du mauvais côté. Les règles sur la révision de la rémunération et sur le droit de l’auteur de recevoir des informations sur l’exploitation de l’œuvre, qui pour d’autres types d’œuvres permettent à l’auteur de revenir sur la question du paiement, ne s’appliquent pas aux auteurs de logiciels : l’article L. 131-5, IV, et l’article L. 131-5-1, IV, l’écrivent, et c’est la transposition française de l’article 23, paragraphe 2, de la directive (UE) 2019/790. Un programmeur qui estime que le système s’est révélé plus précieux que les deux parties ne l’attendaient ne peut donc pas, sur ce fondement, réclamer une rémunération supplémentaire.

Ce qui reste, c’est la possibilité d’être nommé comme auteur et la protection contre une utilisation de l’œuvre qui porterait atteinte à l’honneur et à la réputation, et c’est un risque considérablement plus petit, avec lequel on peut vivre. L’important est seulement de ne pas confondre deux choses : la transformation comme question de droit moral n’est pas un obstacle, mais la transformation comme part patrimoniale exige toujours l’autorisation de son titulaire, donc, si la part patrimoniale est restée chez l’agence, la réécriture du système a toujours besoin de son accord.

Ce que la loi donne même sans bon contrat

Même à une entreprise qui n’a rien formalisé, la loi donne quelques facultés, et il vaut la peine de savoir lesquelles un contrat peut retirer et lesquelles il ne peut pas. L’article L. 122-6-1, I, permet à la personne ayant le droit d’utiliser le logiciel d’accomplir les actes de reproduction, de traduction, d’adaptation ou d’autre transformation nécessaires pour permettre l’utilisation du logiciel conformément à sa destination, y compris pour corriger des erreurs, mais l’auteur peut se réserver par contrat le droit de corriger les erreurs et de fixer les modalités de ces actes, donc un contrat peut retirer cette faculté, et beaucoup de contrats le font.

La copie de sauvegarde est un cas différent, et c’est le seul de cette section qu’un contrat ne peut pas retirer, parce que l’article L. 122-6-1, II, dispose que la personne ayant le droit d’utiliser le logiciel peut faire une copie de sauvegarde lorsque celle-ci est nécessaire pour préserver l’utilisation du logiciel, et cela correspond à l’article 5, paragraphe 2, de la directive 2009/24/CE. L’article 8 de la directive dispose en outre que toute disposition contractuelle contraire à l’article 6 ou aux exceptions prévues à l’article 5, paragraphes 2 et 3, est nulle et non avenue.

Ici, il faut être précis, parce que la différence est fine et facile à exagérer : le code français, à l’article L. 122-6-1, déclare nulle et non avenue toute stipulation contraire aux II, III et IV, c’est-à-dire à la copie de sauvegarde, à l’observation du fonctionnement et à la décompilation. La France a donc repris, pour ces trois exceptions, l’article 8 de la directive. Il n’est pas exact d’écrire que le code omet cette nullité pour la décompilation ; il est exact de dire que la copie de sauvegarde ne peut pas être ôtée par contrat et que les clauses contraires à l’exception de décompilation sont nulles.

La décompilation, de son côté, n’est permise que de façon étroite et sous conditions : on peut l’accomplir pour obtenir les informations nécessaires à l’interopérabilité d’un logiciel créé de façon indépendante, si ces informations ne sont pas déjà facilement et rapidement accessibles, si l’acte est accompli par la personne ayant le droit d’utiliser une copie ou pour son compte, et s’il se limite aux parties nécessaires à l’interopérabilité. Les informations obtenues ne peuvent pas servir à d’autres fins ni à la création d’un logiciel dont l’expression est substantiellement similaire, et cette issue est utile, mais étroite, et aucune entreprise ne souhaite qu’elle soit la seule.

Le système contient beaucoup de code qui ne sera jamais le vôtre

Un système sur mesure n’est presque jamais seulement le code qu’a écrit le développeur, parce que la plus grande part du volume vient de bibliothèques et d’un framework qui existaient déjà. Ce code ne devient jamais votre propriété, dans aucun contrat, parce que vous recevez une licence de ses auteurs, et cette différence compte précisément lorsque quelqu’un promet de céder tous les droits sur le système.

Les licences permissives ne créent pas de problème, parce qu’elles exigent peu et ne restreignent pas la façon dont le système achevé peut être utilisé dans une activité commerciale. La licence MIT permet d’utiliser, de copier, de modifier, de fusionner, de publier, de distribuer et de vendre, pourvu que l’avis de droit d’auteur et la licence elle-même soient conservés, et le logiciel est fourni en l’état, sans garantie, tandis que la licence Apache 2.0 y ajoute une licence de brevet expresse et exige de signaler les modifications apportées. Les deux sont compatibles avec un système commercial fermé, la plupart des frameworks contemporains relèvent de l’une ou de l’autre, et c’est précisément pour cela que cette part du système n’appelle d’ordinaire aucune négociation.

Les licences copyleft demandent de l’attention, pas de la panique, et c’est précisément ici que l’on raconte le plus souvent des demi-vérités, alors que la Free Software Foundation, dans sa page de questions sur la GPL, écrit clairement qu’une entreprise qui fait tourner un programme GPL modifié sur son propre site web n’est pas tenue de publier le code source modifié, parce que l’obligation copyleft naît lorsqu’on remet des copies à autrui, non lorsqu’on utilise le programme chez soi. Fabriquer et utiliser plusieurs copies au sein d’une même organisation n’est pas une distribution, alors que remettre des copies à d’autres organisations, y compris à des sous-traitants pour une utilisation hors de l’entreprise, l’est déjà.

L’exception est la licence GNU Affero GPL, et c’est précisément sa clause d’interaction réseau (AGPL §13) qui surprend, parce que si vous modifiez le programme et que la version modifiée permet à des utilisateurs de communiquer avec lui à distance par un réseau, alors il faut offrir à ces utilisateurs la possibilité de recevoir le code source correspondant. Les conditions sont deux et les deux sont nécessaires : la modification et l’interaction à distance des utilisateurs, donc il n’est pas exact de dire que toute utilisation d’une licence Affero exige la publication du code source, et il n’est pas exact de dire qu’une seule telle bibliothèque assujettit automatiquement tout le système, parce que cela dépend de la façon dont les composants sont reliés.

Le séquestre chez un tiers, et ce qu’il donne vraiment

Le séquestre de code source (escrow) est un montage à trois dans lequel le développeur remet le code source à un dépositaire neutre, et le dépositaire ne le délivre au commanditaire que si survient le cas décrit dans le contrat, les cas typiques étant l’insolvabilité, la cessation d’activité ou un manquement essentiel aux obligations de maintenance après mise en demeure. La France n’a pas de loi qui fixerait ces cas ou même les énumérerait, donc tout ce qui opère ici est ce que les parties ont elles-mêmes écrit, et c’est pourquoi le contrat de séquestre doit se lire avec autant d’attention que le contrat de réalisation lui-même.

Le séquestre donne exactement ce qui a été déposé, et seulement lorsque survient ce qui a été décrit, mais à lui seul il ne cède pas le droit d’auteur, parce qu’il faut se souvenir ici encore de l’article L. 111-3, et il n’apprend à personne à faire tourner le système. L’entreprise NCC Group, qui vend ce service depuis des décennies, le reconnaît elle-même dans ses matériaux : que le code source se trouve dans le coffre est une chose, savoir le compiler en est une autre, et c’est précisément pour cela que la même entreprise vend aussi la vérification du contenu déposé. C’est l’appréciation d’une partie intéressée, mais c’est un aveu sur le point faible de son service principal, et c’est pourquoi on peut s’en servir.

Les systèmes d’aujourd’hui ont aussi une seconde lacune, qui n’a plus rien à voir avec le droit : si le système fonctionne comme un service sur l’infrastructure du développeur, alors le code source sans l’environnement d’exécution, la configuration et les données ne résout que la plus petite part du problème, parce qu’il reste au destinataire une archive, non un système qui tourne. Les praticiens comblent cette lacune en complétant le séquestre par un accord sur qui reprend l’environnement et sur ce qui se passe si les factures d’hébergement restent impayées, et ce sont précisément ces points qui, sur les formulaires types de séquestre, n’apparaissent d’ordinaire pas.

Il existe aussi un obstacle juridique, que l’on rencontre dans la procédure collective : le bien mis sous séquestre et sa remise peuvent entrer en conflit avec le régime de la masse, donc précisément dans le cas pour lequel le séquestre est le plus souvent acheté. La conclusion pratique n’est pas de renoncer au séquestre, mais de ne pas le tenir pour un substitut à une cession écrite des droits et à une remise régulière du code source.

Où se trouve le dépôt, et où se trouvent les données

La question de savoir où se trouvent le code et les données décide davantage que la question de savoir à qui ils appartiennent, parce que des droits sans accès sont un problème lent. La documentation de GitHub décrit clairement qu’une organisation est un compte partagé, auquel appartiennent les dépôts, que l’on ne se connecte pas en tant qu’organisation, parce que chacun s’identifie avec un compte personnel, et que les propriétaires de l’organisation ont toujours accès à tous les dépôts ; un dépôt peut appartenir à un compte personnel ou à une organisation, et ce choix compte plus qu’il n’y paraît.

Si le dépôt appartient au compte personnel du développeur, alors l’accès du client n’est qu’un accès de collaborateur, que le titulaire du compte peut retirer à tout moment, et, en quittant le projet, il emporte aussi l’adresse elle-même. Si le dépôt appartient à l’organisation du client, dans laquelle le développeur a été invité comme membre, alors le départ signifie le retrait d’un accès et rien de plus, et c’est l’une des rares choses de cet article que l’on peut réparer en une journée, sans avocat.

Les données sont une question à part, et il n’y est plus question de droit d’auteur : si le développeur traite des données à caractère personnel pour votre compte, c’est-à-dire s’il fait tourner l’environnement de production, s’il accède aux données de clients ou de salariés ou s’il constitue des sauvegardes, alors vous êtes responsable du traitement et le développeur est sous-traitant au sens du règlement général sur la protection des données (RGPD). L’article 28 du règlement exige un contrat écrit portant des points précis : l’objet et la durée du traitement, sa nature et sa finalité, les types de données et les catégories de personnes concernées, ainsi que les droits et obligations du responsable du traitement.

Un travail de simple écriture de code, sans accès à des données à caractère personnel, ne déclenche pas l’article 28, donc tout contrat de réalisation n’a pas besoin d’un contrat de sous-traitance. La frontière est simple et vérifiable : si le développeur peut voir de vraies données clients, alors il en faut un, mais s’il ne travaille qu’avec des données de test et ne voit pas l’environnement de production, alors il n’en faut pas, et cela en soi est un argument pour que l’environnement de test soit distinct.

Ce que vous gagnez, et ce que vous prenez en charge en même temps

La logique de cet article a été jusqu’ici unilatérale, donc il est juste de nommer aussi l’autre face : le plein contrôle d’un système sur mesure n’est pas seulement un gain, mais aussi un ensemble d’obligations qui ne disparaissent pas. Pour un produit du marché, la maintenance, les correctifs de sécurité et la compatibilité avec de nouveaux environnements sont pris en charge par l’éditeur, et cela entre dans l’abonnement, alors que pour un système sur mesure c’est le titulaire qui les assure, c’est-à-dire vous, et c’est une dépense directe, qui apparaît chaque année, que quelque chose change ou non dans le système.

La deuxième chose que vous prenez en charge est le vieillissement du système, qui s’accumule en silence et ne se manifeste d’aucune façon tant que personne ne le cherche. Le système repose sur des versions de langage et de framework pour lesquelles les éditeurs fixent des dates de support, et, passé ces dates, les nouvelles vulnérabilités ne sont plus corrigées, même si le système continue de fonctionner exactement comme avant et qu’aucun écran n’en avertit. Ce n’est pas une interdiction de faire tourner un système vieillissant, mais c’est le moment où le titulaire reprend le risque, et les dates concrètes, pour PHP et Laravel, nous les avons rassemblées dans l’article sur ce que signifie choisir PHP et Laravel, donc nous ne les répétons pas ici.

La troisième est le marché, et pour une plateforme du marché un spécialiste se trouve comparativement facilement, parce qu’on les forme et qu’ils sont plusieurs, alors qu’un système sur mesure n’est connu que de ceux qui l’ont construit, et qu’il faut laisser à un nouveau développeur le temps de s’y familiariser avant qu’il puisse y changer quoi que ce soit en sécurité. Cela ne signifie pas que la reprise est impossible, mais cela signifie qu’elle coûte, et ce coût apparaît précisément au moment où la relation avec le développeur précédent a déjà pris fin.

C’est précisément pour cela que la question de ce qui vous appartient n’est pas une formalité juridique, mais la question de combien coûtera le prochain choix. Une entreprise qui a une cession écrite, le code source dans son propre dépôt et une liste des composants utilisés peut chercher un nouveau développeur dans la semaine, alors qu’une entreprise sans tout cela commence par établir ce qu’il lui est seulement permis de faire, et seulement ensuite se met à chercher, et c’est la différence entre négocier en position de force et négocier par nécessité.

Ce qu’il faut inscrire dans le contrat, tant qu’il est encore temps

Toutes les sections précédentes aboutissent à un petit ensemble de points qu’il vaut la peine d’inscrire dans le contrat avant le début des travaux, parce qu’après la remise la position de négociation est beaucoup plus faible. Le premier est la cession écrite des droits patrimoniaux, en nommant quels droits passent, sur quel territoire et pour quelle durée, parce que, si le lieu n’est pas indiqué, l’article L. 131-3 n’offre pas de palliatif géographique : l’acte est simplement incomplet. Le deuxième est l’attestation que l’agence les a obtenus de ses salariés et de ses sous-traitants, parce que, sans ce maillon, la cession elle-même peut être vide.

Le troisième est la remise régulière du code source et de tout ce qui est nécessaire pour le compiler, non une remise unique à la fin du projet, et le quatrième est que le dépôt se trouve dans le compte d’organisation qui est le vôtre dès le premier jour. Le cinquième est une liste des composants open source avec leurs licences, parce que, sans cette liste, personne ne saura plus tard ce qu’il y a dans le système et à quelles conditions ; le sixième est un contrat de sous-traitance si le développeur voit de vraies données, et le septième est un accord sur ce qu’il advient des environnements, des clés et des accès à la fin de la collaboration.

Aucun de ces points n’exige un long texte, aucun d’eux n’est en contradiction avec une bonne collaboration, et aucun développeur honnête n’y objecte, parce qu’ils consignent précisément ce que les deux parties pensent de toute façon. La seule chose qu’ils changent, c’est que l’accord ne dépend plus de ce que les personnes concernées travaillent encore, trois ans plus tard, dans la même entreprise, ni de ce que quelqu’un se souvienne de ce qui a alors été dit oralement. Ces points, il vaut la peine de les demander à n’importe quel développeur, y compris à nous, et de les inscrire dans le contrat avant le début des travaux. Notre page de développement logiciel sur mesure promet aujourd’hui de remettre le code source, la documentation et la configuration de l’infrastructure à la fin des travaux, et c’est précisément pour cela que le troisième point de cette liste, à savoir une remise régulière en cours de travaux, mérite d’être discuté à part, plutôt que d’être tenu pour allant de soi. Si vous voulez que nous examinions un contrat déjà existant, écrivez-nous.