AccueilÀ proposServicesNos ProduitsSecteur MédicalBlogContactDemander un Devis
Accueil/Blog/Que deviennent vos systèmes si l'agence disparaît
Technologie14 déc. 20243 min de lecture

Que deviennent vos systèmes si l'agence disparaît

Accès, propriété, documentation et exportabilité — les conditions de transfert à régler dès le départ.

Que deviennent vos systèmes si l'agence disparaît

Une agence ferme, un contrat se termine dans de mauvaises conditions, ou la seule personne qui comprenait le système s'en va tout simplement — et une entreprise découvre, au pire moment possible, qu'elle n'a en réalité jamais eu les clés de ce qu'elle a payé. Ce n'est pas un cas limite rare ; c'est le résultat prévisible de ne jamais demander, au début d'une relation, ce qu'il advient de tout si cette relation prend fin.

L'accès est la première chose à régler, pas la dernière

Qui détient l'enregistrement du domaine, le compte d'hébergement, le dépôt du code source, les clés API tierces dont dépend le système — et ces comptes sont-ils au nom de l'entreprise elle-même, ou de l'agence, avec l'entreprise en simple invitée. Cette question est facile et légèrement gênante à poser avant de signer un contrat, et très difficile et très coûteuse à résoudre après qu'une relation s'est déjà dégradée. La bonne réponse, dans presque tous les cas, est que la propriété principale de chaque compte revient à l'entreprise, l'agence recevant un accès pour effectuer le travail — pas l'inverse.

La propriété du code est une question précise et contractuelle

« Nous l'avons construit, donc nous le possédons jusqu'à ce que vous nous payiez pour le remettre » est un modèle économique légitime pour certaines agences, et un problème sérieux si une entreprise n'a pas réalisé que c'était l'arrangement qu'elle acceptait. Le contrat devrait indiquer clairement, par écrit, qui possède le code et les actifs produits, si cette propriété est immédiate ou conditionnée au paiement final, et ce qu'il advient de cette propriété si le contrat prend fin prématurément — un langage vague ici n'est pas un oubli, c'est souvent exactement l'ambiguïté dont dépendra plus tard un transfert difficile.

La documentation est ce qui rend la propriété réellement utilisable

Posséder un code que personne ne peut lire équivaut presque à ne rien posséder. Un système sans documentation de son architecture, de ses variables d'environnement, de son processus de déploiement et de ses décisions clés n'est, en pratique, exploitable que par la personne qui l'a construit — ce qui signifie que l'entreprise n'a pas réellement réduit sa dépendance à l'agence en détenant simplement les fichiers, elle a juste rendu cette dépendance plus difficile à voir. Exiger une documentation de transfert basique comme livrable, et non comme extra facultatif, est ce qui transforme la propriété technique en indépendance pratique.

L'exportabilité est le test qui révèle la vraie dépendance

Un système construit sur un outillage propriétaire que seule l'agence d'origine peut faire fonctionner, ou sur une plateforme qui rend l'exportation des données et de la configuration difficile ou impossible, crée une dépendance quel que soit ce que dit le contrat sur la propriété. Le test honnête est simple : un autre développeur compétent pourrait-il reprendre ce système et continuer à y travailler dans un délai raisonnable, en utilisant uniquement ce qui a été transmis — et si la réponse est réellement incertaine, cette incertitude mérite d'être résolue avant que le système soit construit, pas après le départ du développeur d'origine.

Pourquoi c'est le moins cher à régler avant la première facture

Chacune de ces conditions est une petite négociation calme au début d'une relation, et une négociation stressante et sans levier après que quelque chose a déjà mal tourné — demander une documentation de transfert à une agence encore activement engagée ne coûte presque rien ; la demander à une agence déjà partie coûte énormément, si c'est même possible.

Cela s'inscrit aux côtés de la même décision acheter, construire ou configurer — le bon choix technique ne reste bon que si l'entreprise peut réellement continuer à faire fonctionner le système, peu importe qui l'a construit.

Notre équipe logicielle remet la pleine propriété, la documentation et des systèmes exportables en standard, pas comme un extra négocié — car un client qui pourrait partir proprement, et qui choisit de rester, est le seul type de relation qui vaille la peine.

Tous les articles
Partager

Besoin de le faire, pas seulement de le lire ?