À qui doit appartenir le code du logiciel que vous imprimez ?

L'écran de travail et le produit livré ne sont pas les mêmes

Imaginez qu'une application d'appel d'offres ait été développée pour votre entreprise. Les employés se connectent, sélectionnent des produits et reçoivent un PDF. En termes d’utilisation quotidienne, le travail peut sembler terminé. Cependant, lorsque le développeur qui modifiera la grille des prix s'en va, on ne sait pas encore si une autre équipe pourra faire tourner l'application. La question du code source devient importante à ce stade. Discutez des possibilités d'utiliser l'écran, de modifier le logiciel et de l'exécuter séparément à un endroit différent au début du projet. Ne les traitez pas comme des soumissions qui signifient la même chose ; Précisons quel dossier et quel document sera remis pour chacun d'eux.

Cet article ne détermine pas l'issue juridique d'un contrat. L'étendue des droits est évaluée en fonction du contrat, des composants utilisés et du droit applicable. Examinez les clauses du contrat avec un expert juridique si nécessaire. La seule chose qui peut être faite techniquement est de traduire le livrable attendu en une liste compréhensible. Quelle partie est développée spécifiquement pour vous, quelle partie est utilisée comme service prêt à l'emploi et quelle partie est basée sur une bibliothèque tierce ? Sans cette distinction, il peut être trompeur de supposer que tout le code sera livré dans les mêmes conditions.

Détermine le modèle de livraison dont vous avez besoin

Dans un service d'abonnement prêt à l'emploi, on ne peut pas s'attendre à ce que le fournisseur fournisse le code source. Au lieu de cela, l'exportation des données, l'accès à la fin du service et les possibilités d'intégration sont évalués. Dans une application spécifique pour vous, le réservoir de soudage, la description de l'installation et les conditions de modification peuvent être demandés pour être inclus dans la livraison. Les deux modèles répondent à des exigences différentes. Ne prenez pas votre décision uniquement sur la base du prix initial. Si l'application gère l'activité principale de l'entreprise, la nécessité de pouvoir continuer avec un autre fournisseur peut être plus évidente.

La livraison demandée doit être compatible avec la portée du projet. Par exemple, lorsque vous rédigez les écrans de l’application pour vous, vous ne pouvez pas utiliser le logiciel interne du service cloud. Cependant, vous souhaiterez peut-être qu'il documente quelles données ont été envoyées à ce service et comment la connexion a été établie. Au lieu de supposer qu'une livraison non incluse dans l'offre aura lieu automatiquement plus tard, clarifiez la question par écrit.

Quelles informations doivent figurer à côté du code ?

Avoir les fichiers sources dans un dossier est un bon début ; à elle seule, elle ne suffit pas pour assurer une prestation durable. Quelle version du code est disponible, quel outil de développement est utilisé et comment les versions de dépendances sont-elles corrigées ? Les noms des variables de configuration, leurs valeurs d'instance et la méthode sécurisée de provisionnement doivent être documentés. Les mots de passe ou clés réels ne doivent pas être placés dans le référentiel de code. La nouvelle équipe devrait être en mesure d'installer l'application en acquérant les secrets dans le cadre d'un processus distinct et autorisé. Écrire clairement des informations confidentielles sur l'environnement de production dans le document de livraison ne facilite pas la livraison ; crée un nouveau risque.

La structure de la base de données, les étapes d'installation, les exemples de données de test et les instructions de récupération de sauvegarde doivent également être inclus dans le package. Enregistrez les tâches planifiées, les connexions de services externes et les emplacements de stockage de fichiers. Cette exigence doit être connue si un rapport est généré uniquement avec la police sur un serveur particulier. Décrivez également les rôles d'utilisateur et les actions que l'administrateur peut effectuer. Il n'est pas nécessaire que ces documents décrivent tous les détails de la demande dans un long livre ; La nouvelle équipe doit fournir des informations complètes sur la façon d'exploiter le système en toute sécurité.

Dépendances et conditions d'utilisation séparées

L'application peut utiliser une bibliothèque open source, un composant payant ou un module partagé du fournisseur. Leurs conditions d'utilisation ne sont pas les mêmes. Tenir à jour un inventaire du nom du composant, de la version, de la source de licence et des exigences de renouvellement. Si un composant payant est enregistré dans le compte du développeur, demandez à l'avance comment l'utiliser dans la nouvelle équipe. L'achat ne signifie pas nécessairement un transfert ou une utilisation illimitée dans tous les environnements. Vérifiez la condition pertinente à partir du document de licence réel ; Ne prenez pas de décision basée sur une hypothèse générale.

Conserver le référentiel de code dans un compte professionnel peut en faciliter l'accès ; La possession d'un compte à elle seule n'explique pas tous les droits d'utilisation. Les contributions fournies par le développeur et les limites existantes doivent être indiquées dans le contrat. De même, la propriété des données et la possibilité de migrer les données doivent être traitées séparément du code. Si vous ne parvenez pas à exporter les enregistrements clients lors du passage à une nouvelle équipe, vous pourriez rencontrer des problèmes de migration même si le code a été livré. Transfert de données entre systèmes alors incluez-le dans le plan de livraison.

Vérifier la livraison avec un petit test de réception

À la fin du projet, mettez en place un environnement de test propre au lieu de simplement compter les fichiers. Exécutez l'application à l'aide du document de livraison, connectez-vous avec l'exemple d'utilisateur et effectuez une opération de base. Restaurez ensuite la sauvegarde et exportez les exemples de données. Si une étape est requise au cours du processus et n'est pas incluse dans le document, ajoutez-la. Effectuez des tests sans diffuser les données de production ni modifier le système en direct. Ainsi, la différence entre le fichier livré et la livraison utilisable est clairement visible.

Conservez ensemble l'adresse du référentiel, la version de livraison, la recette d'installation, l'inventaire des dépendances, l'exportation des données, le responsable et les étapes de détachement dans la liste de contrôle finale. Cette liste sera mise à jour lorsque des modifications seront apportées. Le but n’est pas d’utiliser le même contrat sur tous les projets, mais de définir la prestation qui fera vivre votre entreprise. Lorsque le modèle, l'offre et le dossier d'acceptation évoqués au début correspondent, le changement de fournisseur devient une tâche technique plus compréhensible.

Questions fréquentes

Obtenir le code source seul suffit-il ?

Non. La documentation d'installation, les dépendances, les conditions d'utilisation appropriées et la vérification du fonctionnement dans un environnement propre sont également requises.

La livraison de code est-elle attendue dans chaque logiciel ?

Le modèle de livraison du service d'abonnement prêt à l'emploi et du logiciel développé spécifiquement pour vous peut être différent. Définissez clairement le modèle et la portée dans le contrat.

Comment tester le changement de fournisseur ?

Incluez dans les tests d'acceptation la possibilité pour une nouvelle équipe autorisée de configurer l'environnement de test avec le package de livraison et d'exporter les exemples de données.