Prévoir la sortie d’une solution logicielle dès son choix

Dès le choix d’une solution logicielle, un plan de sortie devrait préciser quel changement devra être possible plus tard. Une nouvelle équipe de développement, un nouvel hébergement et le remplacement complet des services connectés sont des projets différents. Définir cette limite tôt permet d’accepter consciemment certaines dépendances et de convenir des preuves nécessaires.

Le code ouvert laisse subsister des dépendances externes

Une licence conforme à l’Open Source Definition de l’OSI comprend notamment l’accès au code source et la possibilité de distribuer des modifications et des œuvres dérivées. Elle ne transfère pas automatiquement un service de recherche hébergé, un compte d’entreprise ou les documents qui y sont stockés.

Dans le portail fictif P-18, le code de l’application est sous licence open source. Les documents originaux sont dans un stockage de fichiers distinct, les affectations des personnes aux projets dans l’application et l’index de recherche chez un service managé. Un nouveau développeur peut modifier le code. Retrouver les mêmes documents avec les mêmes règles d’accès après un changement de fournisseur reste une question distincte.

Distinguer les périmètres avant l’achat

Trois objectifs sont envisageables dans cet exemple. Le tableau indique les preuves attendues, pas une migration déjà réalisée.

Un index de recherche copié ne remplace pas automatiquement les documents originaux et leurs correspondances. Une reconstruction exige de savoir d’où proviennent le texte, les identifiants stables des documents et les droits. Un format d’index compris seulement par l’ancien service n’est pas encore une preuve de transfert exploitable pour un autre moteur.

Conserver délibérément une dépendance peut être pertinent

Un service managé peut apporter un bénéfice qui justifie l’effort d’un changement ultérieur. Le guide du gouvernement britannique sur la dépendance technique recommande de mettre en balance l’impact du changement et le bénéfice de rester. Il aborde aussi les formats ouverts et la disponibilité des connaissances dans l’équipe.

Pour la deuxième ligne du tableau, continuer à utiliser le service de recherche peut être raisonnable. Il faut alors préciser qui administre le compte, peut accorder des accès et prendra en charge le service après le changement. Si ce service doit lui aussi être remplaçable, l’accès aux données et l’essai d’une alternative s’ajoutent au périmètre. L’étiquette « open source » ne tranche pas ce choix.

Inscrire le périmètre retenu dans la commande

Une formulation concrète pour l’exemple pourrait être : « L’application doit pouvoir changer d’hébergement. Le stockage documentaire et la recherche restent dans nos comptes d’entreprise. Dans le nouvel environnement, nous testons l’ouverture d’un document autorisé et le refus de ce même document pour un rôle restreint. »

La dépendance conservée devient ainsi visible et le contrôle est lié à une tâche concrète. Si un changement complet de produit devient nécessaire plus tard, l’entreprise peut déterminer quelles données, interfaces et connaissances supplémentaires manquent. Le plan de sortie doit évoluer avec le système.

Sources

• OSI — The Open Source Definition

• GOV.UK — Managing technical lock-in in the cloud