Portabilité du projet
Cela s'est déjà vu que des entreprises privées françaises passent sous giron étranger, ou plus simplement qu'une entreprise cesse son activité. Cela n'est malheureusement pas de notre ressort mais il faut quand même limiter la casse.
Pour chaque entreprise privée que vous choisissez, il faut que la fonctionnalité dont vous avez besoin se base sur des standards (nous excluons les projets de niches qui font de la R&D et où les standards peuvent ne pas encore exister).
Par exemple :
- Envoi d'email : utiliser le protocole SMTP plutôt que l'API interne du provider permet d'interchanger facilement les acteurs ;
- Hébergement applicatif : avoir le produit final disponible dans un "container" (type image Docker ou Buildpack) permet une compatibilité très large avec les hébergeurs ;
- …
Sans parler des problématiques de services tiers utilisés, il se peut aussi que votre produit soit transféré dans une autre entité interne, où l'hébergeur et les outils sont différents… C'est là qu'avoir une certaine portabilité aide. Après il faut rester lucide, toute migration demande un investissement. Il faut juste essayer de limiter les ajustements à ce qui est environnant et non à ce qui est relatif au code applicatif.
Un début de réponse est de simplifier la stack technique au maximum afin d'être le plus possible interopérable.