Les projets avec code source exporté doivent passer un test de portabilité

Exporter du code source prouve que vous avez reçu des fichiers. Cela ne prouve pas que le projet peut être compilé, démarré, authentifier des utilisateurs, lire des données de production ou être déployé après la disparition du créateur d’applications IA d’origine. Considérez la portabilité comme un test d’acceptation, pas comme une case à cocher dans un contrat commercial.

J’ai repris suffisamment d’applications générées pour me méfier d’un dépôt propre au premier regard. Les pannes coûteuses se cachent généralement hors du code applicatif évident : une requête d’exécution vers un service du fournisseur, un callback d’authentification enregistré dans le tenant de quelqu’un d’autre, une politique de base de données jamais versée dans le contrôle de version, ou un réglage de déploiement présent uniquement dans un tableau de bord géré. Un projet n’est portable que si votre équipe peut reproduire son comportement fonctionnel à partir de l’export et des services externes documentés, sous des comptes qu’elle contrôle.

Les projets avec code source exporté peuvent encore dépendre du créateur

Un projet dont le code source est exporté ne fonctionne de façon autonome que si chaque dépendance nécessaire au build et à l’exécution est disponible, documentée, transférable et utilisable sous licence hors du créateur. Cette définition est plus exigeante que « le dépôt compile ». Elle couvre tout le parcours, d’une machine vierge jusqu’à une version de production fonctionnelle, avec l’identité, les données, les tâches planifiées, les secrets, les règles réseau et la récupération.

Trois affirmations différentes sont souvent confondues. L’accès au code source signifie que vous pouvez examiner les fichiers. L’indépendance de build signifie que vous pouvez produire des artefacts sans appeler le créateur. L’indépendance à l’exécution signifie que ces artefacts continuent de traiter de vraies requêtes sans lui. Un fournisseur peut satisfaire la première affirmation et échouer sur les deux autres.

La distinction a une conséquence contractuelle directe. Si le contrat promet un « export de code source », vous pouvez recevoir un dossier React, un manifeste de paquets et un README tout en restant dépendant d’un SDK propriétaire ou d’une passerelle hébergée. Demandez plutôt un résultat opérationnel : un ingénieur autorisé doit pouvoir compiler et exécuter la version acceptée dans un environnement propre en utilisant des comptes appartenant au client.

Définissez le périmètre avant les tests. Les services gérés ne constituent pas automatiquement un échec de portabilité. La plupart des applications sérieuses dépendent d’un cloud, d’un prestataire de paiement, d’un fournisseur d’e-mails ou d’un service d’identité. La question est de savoir si vous avez choisi ces dépendances en connaissance de cause et si vous pouvez les déplacer ou les remplacer dans le cadre de votre propre contrat. Un service caché du fournisseur, auquel il est impossible de souscrire séparément, est très différent d’une base PostgreSQL documentée dans votre compte cloud.

Créez un registre de dépendances avec quatre champs pour chaque composant externe : propriétaire, rôle, voie de remplacement et comportement en cas de panne. Le « propriétaire » est le titulaire légal du compte, pas la personne qui connaît le mot de passe. La « voie de remplacement » peut être une procédure de migration, une interface que vous pouvez réimplémenter, ou une décision explicite de conserver le service. Le « comportement en cas de panne » indique ce que voient les utilisateurs lorsqu’il est indisponible. Si le vendeur ne peut pas renseigner ces champs, l’export n’est pas assez expliqué pour en évaluer le risque.

Le meilleur premier test est très ordinaire : coupez l’accès au compte du créateur et essayez l’application. Révoquez ses jetons dans une copie de préproduction, bloquez ses domaines connus à la frontière réseau, puis observez ce qui échoue. Ne commencez pas par lire chaque fichier. Les observations à l’exécution révèlent des dépendances qu’une revue de code ne détecte pas, notamment la configuration injectée et les appels effectués par des paquets compilés.

Tracez l’application pendant de vrais parcours

Les callbacks d’exécution se révèlent lorsque vous observez le DNS, les connexions sortantes, les requêtes du navigateur et les tâches en arrière-plan pendant des parcours représentatifs. Une page d’accueil qui se charge ne prouve pas grand-chose. Testez la connexion, la récupération de mot de passe, l’envoi de fichiers, la recherche, les transitions de facturation, l’envoi d’e-mails, les tâches planifiées, les actions d’administration et toute fonctionnalité reposant sur l’IA que le produit vend réellement.

Exécutez l’application sur un réseau de préproduction neuf où le trafic sortant est journalisé. Ne lui accordez que les destinations figurant dans le registre de dépendances. Commencez par une politique de refus pour le trafic non répertorié si votre environnement le permet. Chaque requête bloquée devient une question : est-elle nécessaire, s’agit-il de télémétrie facultative, d’une vérification de mise à jour ou d’un appel non documenté au plan de contrôle ?

Les outils de développement du navigateur comptent, car certaines dépendances ne touchent jamais votre serveur. Examinez l’onglet Réseau après avoir vidé le stockage et ouvert une nouvelle session. Regardez les hôtes de requêtes, les requêtes preflight en échec, les connexions WebSocket, les scripts chargés et les redirections. Un frontend peut appeler directement une API du créateur alors que le dépôt serveur semble autonome. Les service workers peuvent aussi préserver un ancien comportement, désinscrivez-les avant de répéter le test.

Dans une arborescence de type Unix, cette recherche fournit un premier inventaire utile :

grep -R -n -E 'https?:|wss?:|fetch[(]|axios|WebSocket|grpc|callback|webhook' .

Attendez-vous à une sortie de la forme path/to/file:line:matching text. Examinez les fichiers de verrouillage générés séparément du code applicatif, car un domaine dans les métadonnées d’un paquet ne prouve pas un appel à l’exécution. À l’inverse, une recherche sans résultat ne prouve pas l’indépendance : des variables d’environnement peuvent assembler les hôtes, des alias DNS peuvent les masquer et des dépendances binaires peuvent faire leurs propres requêtes.

Recherchez séparément les termes du fournisseur, les imports de SDK et les préfixes de variables d’environnement. Examinez ensuite les fichiers de verrouillage pour voir si les paquets proviennent d’un registre public ou d’un registre privé du fournisseur. Un cache réussi peut vous induire en erreur. Supprimez les caches de paquets du langage dans l’environnement de test isolé et reconstruisez avec les seuls identifiants de registre documentés.

Observez assez longtemps le comportement en arrière-plan pour franchir une échéance du planificateur. Un processus web peut sembler sain alors que les consommateurs de files échouent, que les rapports planifiés s’arrêtent et que les nouvelles tentatives de webhook s’accumulent. Déclenchez les tâches manuellement lorsque l’attente de leur horaire normal ralentirait le test. Pour chaque intégration sortante, consignez la destination, la méthode de requête, le type d’authentification, la catégorie de réponse, la règle de nouvelle tentative et la conséquence visible pour l’utilisateur.

N’acceptez pas « ce callback ne sert qu’à la télémétrie » sans tester sa panne. Bloquez-le et répétez le parcours. Une télémétrie facultative doit expirer rapidement ou échouer sans modifier l’opération de l’utilisateur. J’ai vu des appels de journalisation placés dans une transaction de requête transformer une panne analytique sans gravité en enregistrement échoué. L’étiquette ne détermine pas le risque, le chemin du code le fait.

Les SDK propriétaires ont besoin d’une voie de retrait ou de licence

Un SDK propriétaire n’est acceptable que si vous pouvez l’obtenir, compiler avec lui, l’exécuter légalement et le remplacer dans un délai tolérable pour l’activité. Disposer du code de son enveloppe dans l’export ne vous accorde aucun droit sur le SDK, le protocole, le point de terminaison hébergé ou le modèle qui se trouve derrière.

Inventoriez les dépendances à partir des manifestes comme des imports du code source. Pour JavaScript, examinez package.json et son fichier de verrouillage. Pour Go, examinez go.mod et les sommes de contrôle. Pour Flutter, examinez pubspec.yaml et son fichier de verrouillage. Notez les paquets récupérés depuis des dépôts Git, des registres privés, des chemins locaux ou des archives. Ce sont des emplacements fréquents pour masquer des composants appartenant au créateur.

Pour chaque paquet douteux, répondez à quatre questions concrètes :

1. Un nouvel agent de build appartenant au client peut-il télécharger la version exacte ?
2. La licence autorise-t-elle l’usage en production après la fin du contrat avec le créateur ?
3. Le paquet appelle-t-il un service auquel le client peut souscrire directement ?
4. L’interface est-elle assez réduite pour être remplacée, et est-elle testée ?

Faites un build à froid avec des identifiants créés dans une organisation appartenant au client. Ne copiez pas tout le répertoire de configuration d’un développeur dans la machine de test. Vous importeriez des paquets en cache, des réglages implicites de registre et des jetons personnels, ce qui annulerait l’exercice. Une procédure de build correcte commence par la version documentée de la chaîne d’outils et déclare chaque identifiant supplémentaire individuellement.

Générez une nomenclature logicielle si la chaîne d’outils le permet, sans la confondre avec une conclusion sur la portabilité. Une SBOM liste les composants, mais indique rarement qui contrôle un compte distant ou si un paquet contacte son éditeur. Utilisez-la pour rapprocher ce que déclare le dépôt de ce que contient l’artefact construit.

Lorsqu’un client propriétaire est placé derrière un adaptateur étroit, écrivez dès maintenant un test de contrat contre cet adaptateur. Envoyez-lui une requête connue, vérifiez la réponse normalisée et exécutez le même test avec le point de terminaison réseau bloqué. L’échec doit être explicite et limité. Si des appels propriétaires apparaissent dans les composants de vue, les gestionnaires de routes et les modèles de données, chiffrez une refonte avant de signer. Le problème augmente avec le nombre de sites d’appel et le couplage sémantique, pas avec le nombre de lignes du SDK.

Les équipes conseillent souvent de remplacer chaque dépendance propriétaire avant l’achat. Cela paraît prudent, mais peut gaspiller des semaines sur des services que l’acheteur souhaite conserver. Une meilleure règle consiste à supprimer les dépendances indisponibles ou auxquelles il est impossible de souscrire, isoler celles que vous acceptez et associer un coût de migration aux autres. La portabilité, c’est maîtriser ses choix, pas avoir une application sans aucun service externe.

L’authentification dépasse l’arborescence du code source

L’authentification ne se déplace proprement que si le client contrôle le tenant d’identité, les redirections enregistrées, les clés de signature, les identifiants utilisateurs, les modèles d’e-mails et le processus de récupération. Le code applicatif ne couvre généralement qu’une partie de ce système.

Commencez par dessiner le chemin de connexion avec ses véritables étapes. Un navigateur atteint l’application, celle-ci redirige vers un fournisseur d’identité, le fournisseur revient vers un callback enregistré, puis le backend échange ou valide les identifiants. Consignez le propriétaire et l’emplacement de configuration à chaque étape. Si une console n’est accessible que par l’organisation du créateur, exigez son transfert ou son remplacement avant l’acceptation.

L’authentification gérée pose un problème de données particulièrement délicat. La table des utilisateurs de l’application peut stocker un sujet spécifique au fournisseur plutôt qu’une adresse e-mail ou un identifiant interne durable. Exporter les lignes n’aide pas si un nouveau tenant d’identité émet des sujets différents. Testez l’association des comptes, la gestion des doublons, les utilisateurs avec mot de passe, les utilisateurs de connexion sociale, l’inscription à l’authentification multifacteur, les comptes verrouillés et les utilisateurs dont l’adresse e-mail a changé.

OpenID Connect définit la revendication sub comme un identifiant localement unique, jamais réattribué dans le périmètre de l’émetteur. L’émetteur compte. Considérer sub seul comme portable globalement peut rattacher le mauvais enregistrement applicatif après un changement de tenant. Stockez et comparez l’émetteur avec le sujet, puis prévoyez une correspondance explicite pour la migration.

Votre test a besoin d’au moins quatre comptes : un utilisateur standard, un administrateur, un utilisateur désactivé et un utilisateur avec un second facteur d’authentification. Déplacez ou recréez la configuration d’identité dans un tenant appartenant au client, restaurez une copie de préproduction de la base de données, puis vérifiez la connexion réussie et l’accès refusé. Testez aussi la déconnexion, le rafraîchissement des jetons, la réinitialisation du mot de passe, l’acceptation d’invitation et l’expiration de session. Les équipes se souviennent du parcours heureux de connexion et ne découvrent une récupération défaillante qu’après le basculement.

Recherchez dans le dépôt les URI de redirection, identifiants client, noms d’émetteur, domaines de cookies, valeurs d’audience et références aux clés de signature. Gardez les secrets hors du dépôt, mais documentez dans les instructions de déploiement leurs noms, propriétaires, étapes de création et de rotation, ainsi que les formats attendus. Un exemple de fichier d’environnement doit décrire le contrat sans contenir de valeurs actives :

AUTH_ISSUER=
AUTH_CLIENT_ID=
AUTH_CLIENT_SECRET=
AUTH_CALLBACK_ORIGIN=
SESSION_SIGNING_KEY=

N’acceptez pas un tenant partagé du créateur comme arrangement permanent sous prétexte que la migration pourra se faire « plus tard ». Les migrations d’identité concernent chaque utilisateur actif et chaque hypothèse d’autorisation. Transférez le contrôle avant la signature ou faites du remplacement une condition chiffrée et testée de l’accord.

La portabilité de la base de données comprend son comportement et son exploitation

Une sauvegarde de base de données ne suffit pas lorsque les schémas, extensions, politiques au niveau des lignes, déclencheurs, stockage d’objets, files, sauvegardes et règles de connexion vivent en dehors d’elle. La portabilité d’une base signifie que vous pouvez restaurer les données et reproduire le comportement qui les protège et les modifie.

Commencez avec une instance PostgreSQL vide appartenant au client, dans la version majeure documentée. Appliquez les migrations du dépôt dans l’ordre. Si le projet ne comporte aucune migration et nécessite l’import d’un schéma exporté créé par le fournisseur, consignez-le comme anomalie. Un export peut capturer l’état du jour, mais n’explique pas comment la prochaine version modifie cet état en toute sécurité.

Comparez le schéma restauré avec la production ou la préproduction. Vérifiez les tables, colonnes, types, contraintes, index, séquences, vues, fonctions, déclencheurs, extensions activées, rôles, autorisations et politiques de sécurité au niveau des lignes. Beaucoup d’outils de migration omettent les rôles et les réglages propres au fournisseur. Une application peut réussir des tests de lecture simples tandis que des tâches d’administration échouent parce que le rôle restauré n’a pas l’autorisation sur une séquence ou une fonction.

Vérifiez ensuite le parcours des données par un aller-retour contrôlé :

1. Créez un enregistrement via le parcours public de l’application.
2. Lisez-le avec un second utilisateur autorisé lorsque le partage est attendu.
3. Confirmez qu’un utilisateur non autorisé ne peut ni le lire ni le modifier.
4. Mettez-le à jour et supprimez-le via l’application.
5. Restaurez la base dans une autre instance propre et répétez les lectures.

Cette séquence teste ensemble le code applicatif, la politique d’autorisation, les valeurs générées et la capacité de récupération. De simples comptages de lignes en SQL direct ne couvrent pas ces comportements.

Considérez le stockage d’objets comme faisant partie du périmètre de la base lorsque les lignes pointent vers des fichiers envoyés. Exportez les buckets, métadonnées d’objets, règles d’accès, règles de cycle de vie et réglages de génération d’URL. Une base restaurée remplie de clés d’objets ne sert à rien lorsque les fichiers sous-jacents restent dans un bucket appartenant au créateur. Le même avertissement vaut pour les index de recherche et les magasins de vecteurs : décidez de les migrer ou de les reconstruire, puis démontrez la procédure de reconstruction.

Ne mesurez ni la réussite ni l’échec à partir d’une seule petite sauvegarde. Utilisez une copie de taille proche de la préproduction, contenant des textes longs, des valeurs nulles, des caractères non ASCII, de gros objets, des horodatages autour des changements d’heure et des relations représentatives. Vous n’avez pas besoin de benchmarks inventés. Vous avez besoin de preuves que le transfert se termine dans la durée d’interruption autorisée et que l’application se comporte correctement ensuite.

Une affirmation sur les sauvegardes exige une restauration. Identifiez qui planifie les sauvegardes, où les copies sont conservées, qui peut les déchiffrer, comment fonctionne la rétention et comment vous détectez l’échec d’une sauvegarde. Restaurez-en une dans un compte isolé en suivant des instructions écrites. Si seul le créateur peut cliquer sur le bouton de restauration, vous disposez d’une fonctionnalité de service, pas d’un plan de récupération indépendant.

Un pipeline CI manquant signifie que des connaissances produit manquent

Un dépôt exporté sans intégration continue reproductible oblige l’acheteur à redécouvrir les versions d’outils, l’ordre de build, les tests, le conditionnement des artefacts, le moment des migrations de base et les contrôles de mise en production. Ces connaissances font partie du livrable, même si le pipeline interne du vendeur ne peut pas être transféré tel quel.

Cherchez les définitions de pipeline, fichiers de build de conteneur, fichiers de version d’outils, commandes de test, règles de lint, commandes de migration et définitions d’infrastructure. Comparez-les ensuite avec un véritable journal de déploiement. La documentation décrit souvent un build web simple alors que la plateforme gérée génère discrètement de la configuration, injecte un composant serveur, construit un bundle mobile ou exécute des migrations de base de données.

Reconstruisez le pipeline minimal dans un compte CI appartenant au client. Il doit récupérer une révision figée, installer une chaîne d’outils déclarée, télécharger les dépendances, exécuter les tests, produire des artefacts immuables et enregistrer l’identité des artefacts. Le déploiement peut rester manuel pendant le test, mais l’artefact qui atteint la préproduction doit être celui produit par le pipeline.

Un journal d’acceptation compact peut prendre cette forme :

revision: 4f2c9ab
toolchain: declared versions loaded
dependencies: cold install passed
tests: unit and integration passed
artifacts: web, server, mobile
migrations: dry run passed
staging: health and workflow checks passed

Les valeurs diffèrent, mais chaque ligne doit avoir une sortie machine ou un enregistrement interne lié, pas le souvenir d’une personne. Conservez ce journal avec les éléments de preuve d’acceptation.

N’exigez pas la machinerie secrète de déploiement du vendeur si vous n’en avez pas besoin. Exigez suffisamment d’instructions et de configuration pour reproduire le résultat. Un pipeline portable peut cibler un autre produit CI s’il effectue les mêmes étapes indispensables et n’affaiblit pas les contrôles de mise en production.

Les applications mobiles ajoutent les éléments de signature, identifiants de paquet, comptes de store et identifiants de notifications push. Ils sont faciles à oublier car un build source peut fonctionner dans un émulateur sans eux. Vérifiez que le client possède les comptes de distribution et documentez la rotation des certificats. Pour les applications serveur et web, incluez la vérification de domaine, l’émission de certificats TLS, les changements DNS et l’invalidation du cache dans l’exercice de mise en production.

Le test de pipeline se termine par une modification, pas par la reconstruction du commit fourni. Effectuez une modification visible sans danger, ajoutez une migration de base de données annulable, construisez-la, déployez-la en préproduction, vérifiez-la et exécutez le retour en arrière. Cela révèle les artefacts générés qui ont été ajoutés une fois au dépôt mais ne peuvent plus être régénérés.

Épinglez les paquets du système d’exploitation utilisés pour le build ainsi que la chaîne d’outils du langage. Des modules natifs peuvent compiler avec des bibliothèques présentes par hasard dans l’image du créateur. Un nouvel exécuteur échoue alors avant le début des tests applicatifs ou, pire, produit un artefact au comportement différent. Capturez les noms et versions de paquets dans une définition de conteneur ou une description de build équivalente lisible par machine.

Gardez les secrets hors des journaux CI tout en prouvant que le pipeline peut les récupérer depuis un coffre contrôlé par le client. Le test doit créer un identifiant de préproduction à courte durée de vie, l’injecter selon le mécanisme documenté et le faire tourner sans modifier le code source. Si un secret doit être collé dans un tableau de bord fournisseur par le personnel de support, consignez cette dépendance au lieu de la cacher dans des notes de configuration.

Les hypothèses d’hébergement apparaissent lors d’un déploiement en environnement propre

Un déploiement en environnement propre prouve la portabilité lorsqu’une équipe qui ne connaît pas le créateur peut lancer le système dans un environnement appartenant au client, en utilisant seulement l’export, les services déclarés et les instructions écrites. Effectuez-le avant l’acceptation du contrat, avec un temps limité et un journal des problèmes.

Choisissez un environnement correspondant au modèle d’exploitation prévu. Passer d’une plateforme gérée à des machines virtuelles brutes crée du travail sans rapport et peut faire paraître défaillant un projet pourtant portable. Reproduisez les briques nécessaires, comme les conteneurs, PostgreSQL, le stockage d’objets, les tâches planifiées, les secrets et l’équilibrage de charge, sans recréer une magie fournisseur non documentée.

Examinez l’application afin d’identifier les hypothèses concernant les disques locaux inscriptibles, les ports fixes, les sessions persistantes, les en-têtes de proxy de confiance, les noms de région, les noms d’hôtes injectés et les variables d’environnement propres à la plateforme. The Twelve-Factor App recommande de stocker la configuration dans l’environnement et de traiter les services de support comme des ressources attachées. Ces idées restent utiles, mais les seules variables d’environnement ne documentent ni la propriété, ni les formats, ni la création. Associez chaque variable à un enregistrement opérationnel.

Les contrôles de santé méritent des tests directs. Un processus qui renvoie une réussite avant la fin des migrations ou avant la connexion des dépendances requises peut entrer dans une boucle de redémarrage derrière un orchestrateur. Séparez liveness et readiness lorsque le système d’hébergement le permet. Arrêtez la base de données, le stockage d’objets et la file un par un, puis observez les codes de statut, les journaux, le comportement de nouvelle tentative et la récupération au retour du service.

Confirmez la façon dont l’application gère plusieurs instances. Les sessions en mémoire, les répertoires locaux d’envoi de fichiers et les verrous de tâches locaux au processus fonctionnent sur une instance gérée et échouent après une montée en charge. Démarrez deux instances, envoyez les requêtes d’un même utilisateur vers les deux et exécutez des workers de tâches concurrents. Vérifiez que les sessions persistent, que les fichiers restent disponibles et qu’une tâche planifiée ne s’exécute pas deux fois, sauf si elle a été conçue pour être idempotente.

Observez l’arrêt aussi attentivement que le démarrage. Envoyez un signal de terminaison lorsque des requêtes et tâches en arrière-plan sont actives. Le processus doit cesser d’accepter du nouveau travail, terminer ou restituer sans risque les tâches réclamées, fermer les connexions et se terminer pendant le délai de grâce de l’hôte. Un créateur géré peut avoir masqué des arrêts brutaux avec de longs délais d’expiration ou des nouvelles tentatives que votre nouvel hébergeur ne partage pas.

Les journaux et les métriques portent aussi des hypothèses d’hébergement. Vérifiez que l’application écrit des événements structurés vers une destination documentée, retire les secrets et les données personnelles lorsque nécessaire et expose assez d’informations pour diagnostiquer un parcours en échec. Un tableau de bord propriétaire n’est facultatif que si la sortie standard ou un autre canal contrôlé par le client conserve les éléments de preuve nécessaires.

Les affirmations concernant la région et la localisation des données exigent des preuves de configuration. Consignez où s’exécutent l’application, la base de données, les sauvegardes, les journaux et le stockage d’objets, ainsi que les services externes qui reçoivent des données. Un sélecteur de région pour le processus web ne garde pas les données dans un pays si l’authentification ou l’analytique les envoie ailleurs. Le contrat doit préciser qui approuve les changements de ces emplacements.

Koder.ai prend en charge l’export de code source, le déploiement et l’hébergement, les domaines personnalisés, les instantanés et le retour en arrière. Si vous évaluez un projet Koder.ai exporté pour une exploitation autonome, appliquez la même norme d’environnement propre : testez les composants React, Go avec PostgreSQL ou Flutter exportés dans l’environnement que vous comptez posséder, et documentez tout service que vous choisissez de conserver.

Intégrez les conditions de réussite et d’échec au contrat

Le contrat doit définir la portabilité comme un comportement observé, lister l’environnement d’acceptation, attribuer la responsabilité des corrections et préserver assez de temps pour régler les échecs avant le paiement final ou l’enfermement. Un langage vague sur la propriété ne sauvera pas une application que personne d’autre ne peut déployer.

Joignez une matrice d’acceptation plutôt que de vous fier à un paragraphe intitulé « code source ». Chaque ligne doit indiquer une capacité, une procédure de test, le résultat attendu, les éléments de preuve, la partie responsable et la gravité. Couvrez le build à froid, les appels réseau à l’exécution, le transfert d’identité, la restauration de base de données, le stockage de fichiers, le travail en arrière-plan, l’intégration continue, le déploiement propre, la supervision, la restauration de sauvegarde, une petite modification et le retour en arrière.

Utilisez des critères de réussite qu’un tiers peut observer. « Aucune dépendance propriétaire critique » invite à la discussion. « L’application de préproduction réalise les parcours A à F alors que tous les identifiants appartenant au créateur sont révoqués et que les domaines du créateur sont bloqués » peut être testé. Définissez les dépendances autorisées par leur nom et le propriétaire du compte, afin que l’équipe ne confonde pas un service géré approuvé avec un échec.

Exigez la livraison du code source et des éléments opérationnels à une révision figée : fichiers de verrouillage, migrations, définitions de build, configuration d’infrastructure lorsqu’elle est disponible, catalogue des variables d’environnement, registre de dépendances, export de données, plan de migration d’identité, procédures d’exploitation, avis de licence et éléments de signature ou de distribution appartenant au client. Consignez explicitement les exclusions. Le silence ne doit pas valoir acceptation.

Définissez la gravité selon l’effet sur l’activité. L’absence d’un événement analytique facultatif n’équivaut pas à une panne de connexion. Un système utile distingue les blocages qui empêchent le build ou les parcours essentiels, les défauts majeurs qui retirent une capacité importante ou une voie de récupération, et les défauts mineurs avec une solution de contournement documentée. Associez les dates d’acceptation et de correction à ces niveaux sans inventer de calendrier universel.

Définissez aussi les données de test et l’opérateur du test. Les vendeurs démontrent parfois la portabilité avec une base vide et un compte administrateur qui contourne les autorisations ordinaires. Exigez des utilisateurs, rôles, fichiers et tâches en arrière-plan représentatifs, avec le personnel du client exécutant la procédure documentée. Gardez les secrets synthétiques, mais rendez les relations et cas limites réalistes.

Les coûts font partie du dossier de preuve. Consignez les services facturés séparément nécessaires à l’exécution de la version exportée, ainsi que tout niveau minimal, frais de sortie de données ou abonnement à un registre privé identifié par le vendeur. Le test n’a pas à prévoir chaque facture future. Il doit empêcher qu’un export supposément indépendant révèle un contrat fournisseur inévitable seulement après la signature.

Incluez des obligations de coopération pour les services qui ne peuvent pas être transférés immédiatement. Le vendeur peut devoir faire tourner des clés, approuver un export d’identité, déplacer un domaine ou fournir un dernier instantané des données. Nommez l’action et la personne responsable. Une « assistance raisonnable » est difficile à faire respecter lorsque la production est arrêtée.

Préservez le droit de répéter les tests après correction et après l’export final. Les projets générés changent vite, et une correction démontrée sur la révision du mois dernier ne dit rien des nouvelles dépendances ajoutées hier. Épinglez le commit testé et les hachages des artefacts dans le dossier d’acceptation.

Ne laissez pas une clause d’entiercement remplacer ce travail. L’entiercement peut livrer des fichiers après un événement déclencheur, mais des fichiers sans instructions de build à jour, propriété des identifiants et voies de récupération testées peuvent arriver trop tard pour aider. L’indépendance opérationnelle doit exister tant que les deux parties peuvent encore coopérer.

Signez lorsqu’une seconde équipe peut compiler, exécuter, modifier, déployer et récupérer la version acceptée sans aide privilégiée du créateur d’origine. Sinon, vous possédez du code source accompagné d’un projet de migration non résolu, et le prix du contrat doit refléter ce travail.