Contrat de maintenance informatique : la vente après la livraison
Pour un freelance qui livre des automatisations, un contrat de maintenance informatique représente l’abonnement assurant le fonctionnement de ce que vous avez construit chez le client. C’est le jour de la livraison que cela se vend, et non trois mois après, lorsque tout est cassé. Et il ne se vend correctement que si trois règles sont déjà en place : sans elles, vous commercialisez la réparation de vos propres raccourcis.
Le jour où l’employé qui a tout branché s’en va
Le scénario est banal dans une PME. Un salarié motivé a ouvert les comptes, connecté le CRM, branché les relances. Il quitte l’entreprise. Le service informatique ferme son compte le jour de son départ.
Le lendemain, les relances clients ne partent plus. La facturation échoue sur un accès refusé. La synchronisation du CRM tombe sur un jeton expiré. Personne ne sait pourquoi, parce que personne ne savait que tout passait par ce compte.
Le client vous appelle. Si vous êtes le prestataire qui a livré, c’est aussi votre réputation qui est en jeu. Les trois règles qui suivent évitent cet appel, et la troisième transforme le problème en revenu récurrent.
Règle 1 : chaque compte au nom de l’entreprise
Chaque compte qui fait tourner une application appartient à l’entreprise cliente. Jamais à une personne. Le vôtre compris.
Concrètement, faites la liste de tout ce que l’automatisation utilise : hébergement, planificateur de tâches, API d’IA, messagerie, tableurs, CRM, paiement. Pour chaque service, notez l’adresse du compte propriétaire. Si c’est l’adresse personnelle d’un salarié ou la vôtre, c’est une panne qui attend son jour.
La bonne cible : une adresse générique de l’entreprise (du type tech@ ou outils@), avec le moyen de paiement de l’entreprise. Vous et les salariés y avez des accès de membre, révocables un par un. Les clés d’API sont créées depuis ce compte, et la double authentification passe par un appareil de l’entreprise.
Le test : désactivez le compte d’une personne. Rien ne doit casser.
Règle 2 : le code dans un dépôt qui appartient au client
Le code vit dans une organisation GitHub (ou GitLab) au nom du client. Vous y êtes invité comme collaborateur. Le jour où la relation s’arrête, le client vous retire l’accès et garde tout.
Pour un freelance, ça ressemble à donner sa monnaie d’échange. Mais un client qui sait qu’il possède son code signe plus vite, et reste plus longtemps. Personne ne paie un abonnement à quelqu’un qui le tient en otage.
Une commande suffit pour vérifier où pointe un projet :
git remote -v
Si l’adresse affichée est votre compte personnel, le transfert vers l’organisation du client fait partie de la livraison. Les secrets restent hors du code, dans l’hébergeur ou le gestionnaire de secrets du client, et un README dit comment déployer. Pour les mises à jour qui suivront, la méthode est détaillée dans mettre à jour une application client sans casser la prod.
Règle 3 : le guide de passation, relu avec le client
La troisième règle est celle qui vous fait revenir. Elle a deux moitiés : un document, et quelqu’un qui surveille.
Le document, c’est le guide de passation. Une page, sans jargon, écrite pour le client : ce que fait son automatisation, où voir qu’elle tourne, ce qu’il ne faut pas toucher. Claude Code l’écrit très bien à la fin du projet, à condition de lui faire relire tout ce qu’il a construit avant d’écrire une ligne.
La page la plus utile arrive à la fin : « Si ça s’arrête ». Les trois pannes les plus probables pour ce projet précis (un accès expiré, un fichier renommé, un quota atteint), ce que le client peut vérifier en deux minutes, et qui appeler. Qui appeler, c’est vous.
Relisez ce guide avec le client, le jour de la livraison, en séance. C’est souvent à ce moment qu’il pose la question de la maintenance, parce qu’il vient de lire noir sur blanc ce qui peut casser.
Ce que couvre le contrat de maintenance
La seconde moitié de la règle 3, « quelqu’un qui surveille », c’est l’objet du contrat. Pour une automatisation livrée par un freelance, il tient en cinq lignes :
- La surveillance : les alertes d’échec arrivent chez vous, et les exécutions sont vérifiées chaque semaine. Le workflow qui vous prévient avant le client est décrit dans erreur n8n : être prévenu avant le client.
- La correction des pannes : accès expiré, outil tiers qui change son API, quota atteint, fichier renommé, avec un délai de prise en charge écrit.
- Les accès : une revue des comptes et des clés chaque trimestre, et le départ d’un salarié traité le jour même.
- Les petites évolutions : un volume d’heures par mois pour un champ, un destinataire ou une règle de plus.
- Le compte rendu mensuel : exécutions, incidents, ce qui a été corrigé. C’est lui qui rend l’abonnement visible.
Écrivez aussi ce qui n’y entre pas : les nouvelles automatisations et les refontes se chiffrent à part, sur devis. Sans cette ligne, le contrat devient un forfait illimité.
Dernier point, celui que les modèles de contrat pour un parc informatique oublient : la maintenance démarre seulement quand les trois règles sont en place. Si un compte est encore au nom d’un salarié, sa remise en ordre se chiffre une fois, avant le premier mois.
Ce qu’il reste à faire
Servez-vous de votre projet le plus récent et soumettez-le aux trois vérifications : comptes, dépôt, guide de passation. Toute case non remplie représente soit une défaillance future, soit un argument pour suggérer la maintenance au client.
Souvent, le client fidèle qui revient chaque mois débute par celui-ci, comme l’indique la première mission freelance IA. Et avant la livraison, les paramètres de sécurité d’un projet client se trouvent dans Claude Code security.