Nom et descriptif fonctionnel sommaire

Il s’agit ici de mentionner :

• Le nom du logiciel ou de l’application livrée

• Le niveau de version (ou d’état technique, niveau de tag, etc.) livré

• Une description fonctionnelle sommaire (laquelle pourra renvoyer aux spécifications fonctionnelles)

• La liste des principaux modules ou composants, surtout quand ces modules font l’objet d’une facturation additionnelle. Cette liste doit correspondre notamment aux éléments de facturation pour limiter les risques de litige en matière de recette et donc de règlement. Cette liste pourra également comprendre un tableau de correspondance avec la liste des répertoires et fichiers de la livraison, si le nommage des répertoires de sources et/ou de livrable de ces modules n’est pas le même que celui utilisé dans les contrats de licence/maintenance/fourniture.

Remarque : Il arrive fréquemment que le nommage des sources diffère du nommage « marketing » des modules, pour des raisons d’historique, parce qu’à un module commercial correspondent plusieurs modules techniques, etc.

• Toute information complémentaire éventuellement nécessaire pour préciser le périmètre de cette livraison.

Remarque : Dans la mesure où ce logiciel/application est l’objet principal du contrat de licence, d’utilisation et/ou de maintenance, il mérite d’être soigneusement décrit.

Liste des composants externes utilisés

Au niveau du processus de Build

Remarque : la quasi-totalité des applications livrées à des utilisateurs finals comporte un minimum de composants non propriété du prestataire : Open Source, composants d’infrastructure nécessaire au déploiement ou à l’exécution (librairies « run-time”…). Il convient de les lister précisément, tout particulièrement quand le contrat de fourniture prévoit transfert total ou partiel de propriété au client.

Liste des composants utilisés par le processus de build en précisant :

• Nom et niveau de version du composant, nom du propriétaire pour les logiciels propriétaire (le propriétaire pouvant être le prestataire lui-même qui réutilise des composants d’autres applications et dont il veut absolument conserver la pleine propriété),

• Type de logiciels : Open Source, propriétaire

• Statut des licences : licence propriétaire, GPL, LGPL, etc.

• Remarque : « licence gratuite » n’est pas un statut au sens juridique…

• État technique de ces composants : état natif ou modifié, corrigé, complété par le prestataire…

Au niveau du processus d’intégration/packaging

Liste des composants utilisés par le prestataire dans le processus d’intégration en précisant :

• Nom et niveau de version du composant, nom du propriétaire pour les logiciels propriétaire (le propriétaire pouvant être le prestataire lui-même qui réutilise des composants d’autres applications et dont il veut absolument conserver la pleine propriété)

• Type de composant : documentation, données insérées en base (par exemple données cartographiques, liste des codes postaux, images, etc.), logiciels…

• Statut des licences : licence propriétaire, GPL, LGPL…

• Support de livraison : fourniture sur CD, téléchargement avec nom du site…

• État technique de ces composants : état natif ou modifié, corrigé, complété par le prestataire…

Au niveau du processus de déploiement

Liste des pré requis de déploiement pour tous matériels et composants non fournis par le prestataire mentionnant :

• Environnement matériel y compris des dispositifs spéciaux tels que lecteurs de cartes, configuration de disques et plus généralement tout ce qu’il incombera au client de préparer pour la phase de déploiement (que celle-ci soit faite par lui-même ou par le prestataire)

• Nom de chaque composant logiciel : système d’exploitation, moteur de bases de données, dispositifs de connexion à distance pour la télémaintenance…

• Niveau de version de chaque composant logiciel

• Le cas échéant, procédure spécifique d’installation et de paramétrage pour être compatible avec la livraison…

Remarque : Cette partie pourra faire référence à la documentation d’installation ou en reprendre les éléments concernés. Rappelons que cette annexe est un document contractuel qui fera foi en cas de contestation, de litige, d’arbitrage.

Remarque : Cette information est nécessaire quand l’application est installée chez le client utilisateur. Mais elle peut être également « rassurante » quand l’application est fournie en mode SAAS/ASP et déployée chez un hébergeur.

Remarque : environnement matériel doit être précisé. D'autant plus important qu'il y a de plus en plus de logiciels. En terme d'inventaire, il faut avoir les mentions des micrologiciels (tBIOS) : indissociable du matériel (ne peuvent fonctionner sans). Ces informations doivent aussi être conservées.

Description du contenu de la livraison à un utilisateur/client

Il s’agit ici de donner l’arborescence du contenu du support de livraison en listant les principaux répertoires, sous répertoires et fichiers, avec une description sommaire de leur contenu, de telle sorte que le client puisse raisonnablement rapidement identifier :

• Les composants externes qui lui sont fournis avec la livraison et nécessaires pour le déploiement et/ou le fonctionnement de l’application (ceux-ci ayant été décrits ci-dessus),

• Les modules livrables correspondant aux modules listés dans son contrat de licence,

• Tout ce qui concerne le déploiement, le peuplement et le paramétrage initial des bases de données,

• Des jeux de tests à dérouler après déploiement pour s’assurer que la procédure d’installation s’est déroulée normalement (que ces jeux de test soient déroulés par le prestataire ou par le client lui-même),

• Les documentations techniques dont il aura besoin : pour le déploiement, pour l’exploitation, la maintenance, le support, etc. (par exemple : manuel utilisateur, manuel d’exploitation, …)

Remarque : Il ne s’agit pas d’une liste exhaustive de tous les répertoires et fichier, mais d’une description de la livraison permettant au client d’y retrouver rapidement l’essentiel des informations et éléments dont il aura besoin, soit pour déployer et valider, soit pour prononcer sa recette.

Remarque : Il arrive parfois que le client ne respecte pas scrupuleusement les procédures de déploiement et de test, parce qu’il ne prend pas la peine de lire les documentations fournies, parce qu’il fait des économies sur la formation de son personnel etc. Il peut être intéressant pour le prestataire d’apporter alors la preuve de la qualité, complétude et validité des documentations, procédures, informations fournies au client lors de la livraison.

Description du contenu de la livraison destinée à un séquestre

Un certain nombre de contrats de fournitures logicielles prévoient une clause dite « de séquestre/défaillance » par laquelle le fournisseur s’engage à déposer sous séquestre les éléments nécessaires à la reprise de maîtrise en maintenance de l’application livrée par toute personne compétente, en cas de défaillance en maintenance du fournisseur initial.

Cela suppose que soit ajoutés à la liste fournie ci-dessus, un certain nombre de composants et documentations non fournis normalement à l’utilisateur, mais nécessaires à cette reprise de maîtrise en maintenance dans des conditions raisonnables.

La liste de ces éléments complémentaires peut varier en fonction des objectifs des parties, des types de déploiement ou de commercialisation. On pourra donc trouver les cas suivants (non exhaustifs) :

• Commercialisation en mode SaaS/ASP,

• Solutions financières avec un leaser.

• Fourniture à un intégrateur,

• Système de preuve vis-à-vis d’une autorité de tutelle (sanitaire, sécurité, fiscale, traçabilité, Objectif patrimonial,

• Système de preuve en matière de droits d’auteur.

Commercialisation en mode SaaS/ASP :

Ce cas est également assimilable aux solutions outsourcing. En pareil cas, l’utilisateur est dépendant de son fournisseur, non seulement en ce qui concerne la maintenance évolutive, mais également toute la production (exploitation, sauvegardes, sécurité...). Dans la plupart des cas, le fournisseur utilise les services d’un « hébergeur ». En cas de besoin, l’utilisateur aura besoin d’informations et de composants complémentaires tels que :

• Nom et coordonnées de l’hébergeur,

• Descriptif détaillé des composants fournis par l’hébergeur : type de machine (dédiée ou partagée), système d’exploitation (nom, niveau de version, procédure d’installation et de paramétrage), mots de passe d’accès au serveur, nature des composants spécifiques matériels et logiciels complémentaires fournis par l’hébergeur, dispositifs de sécurité, etc.

• Procédure détaillée de déploiement et de paramétrage de l’application client sur l’environnement d’hébergement, mots de passe d’accès, de redirection de noms de domaines, etc.

• Procédures complémentaires d’exploitation utilisées par le fournisseur (gestion de profils utilisateurs, purge des bases de données, procédures de mises à jour de l’application, etc.)

• Systèmes de sauvegarde (miroring), localisation des back-up…

• Plus généralement, toute information permettant au client comme au fournisseur de basculer la production sur un autre site en cas de défaillance de l’hébergeur, par exemple.

Solutions financières avec un Leaser (Société de leasing, de crédit-bail) :

Ce cas est assez proche de celui du déploiement en mode SaaS, à ceci près qu’une société financière s’intercale entre le fournisseur et le client final et que c’est elle qui perçoit les mensualités couvrant la licence, la maintenance applicative, l’hébergement et même souvent le matériel installé en local. Cette société financière peut alors se trouver engagée à millions sur une application et a besoin de sécuriser ses encaissements (autant par des procédures de secours et de sécurité que par des contrats d’assurance). Le « financier » à alors besoin d’être assuré de disposer de tous les moyens pour relancer la production en priorité puis la maintenance applicative dans des délais compatibles avec ceux couverts par son contrat d’assurance par exemple ou dans les délais prévus avec les clients et au-delà desquels des pénalités de retard pourraient lui être imposées. Il peut alors avoir besoin d’informations complémentaires telles que :

• Liste complète des mots de passe de redirection des noms de domaine des clients concernés,

• Liste des mots de passe d’accès aux machines locales des clients pour intervention en maintenance et mise à jour des applications déployées en local,

• Copie des factures de vente et/ou bons de garantie des matériels financés …

Fourniture à un intégrateur

L’intégrateur a a priori vocation à reprendre la maintenance et le développement en cas de défaillance du fournisseur d’origine. C’est souvent pour cette raison qu’un « grand compte » préfère travailler avec un intégrateur, même s’il lui impose d’intégrer telle ou telle solution qu’il a validée comme correspondant à ses besoins. En pareil cas, les contraintes de reprise de la maintenance peuvent imposer des délais plus courts et des pénalités de retard.

L’intégrateur doit alors disposer de toutes les informations techniques lui permettant de reprendre la maîtrise de l’application dans les délais impartis. Il devra alors disposer des informations telles que :

• Normes internes de développement et de nommage,

• Spécifications fonctionnelles et techniques,

• Dossiers d’architecture,

• Scripts de création peuplement et paramétrage initial des bases de données, descriptions des tables, index, etc.

• Quand il y a des composants hardware tels que des cartes spécifiques, nom des sous-traitants, dossiers de conception et environnements de développement correspondants (y compris ceux utilisés par les sous-traitants et dont les licences peuvent être très coûteuses), sources, documentations de conception, fichiers résultants, etc.

Système de preuve vis-à-vis d’une autorité de tutelle

A la demande d’une autorité de tutelle, il peut être demandé de produire des sources, des plans de test et dossiers de validation, que ce soit pour des raisons fiscales, de santé publique, de risques humains ( logiciels embarqués sur des matériels roulants ou volants) etc. Le fournisseur aussi bien que son intégrateur peuvent être amenés à fournir solidairement des informations complémentaires telles que ;

• Dossiers et plans de test,

• Dossier de validation pour mise en conformité avec les exigences de la CNIL, de la FDA, de normes aéronautiques, etc.

• Systèmes de traçabilité,

• Systèmes de sécurisation des données et des transmissions, etc.

Dans le but de prouver qu’ils ont respecté les normes imposées et/ou qu’ils ont testé leurs applications de façon professionnelle et à la hauteur des risques potentiellement encourus pas leurs utilisateurs

Système de preuve en matière de droits d’auteur

En matière de « Droits d’auteur » et pour autant que cela soit nécessaire en matière de « logiciels libres », l’administration de la preuve est dite « de libre parcours ». En d’autres termes, tout ce qui contribue à renforcer le « faisceau de preuves de propriété » est utile. Dans ce cadre, le propriétaire de l’application (notamment quand il s’agit de code source interprété et donc fourni à l’utilisateur) pourra ajouter un certain nombre d’informations complémentaires telles :

• Justification des choix d’environnements de développement et de déploiement, articulation de ces composants, etc. En effet ; si le fournisseur n’est pas propriétaire des environnements qu’il a utilisé, le choix qu’il en a fait n’est pas dû au hasard et sa cohérence d’avec le contenu de son patrimoine en renforcera nécessairement le système de preuve.

• Bases de données de sources (CVS, VSS, Perforce, etc.) donnant l’historique détaillé de tout ce qui a été développé, modifié, ajouté au fil des mois et des années à une application initiale ou entre deux versions de cette application,

• Documents préparatoires au développement, etc.