Beaucoup de dirigeants, lorsqu'ils signent un contrat de développement web, concentrent leur attention sur le devis et les délais, et rédigent la rubrique des livrables d'un simple « un site web, un jeu de code source ». Ce n'est qu'à la fin du projet qu'ils découvrent : les maquettes ne sont pas fournies, les comptes d'administration restent entre les mains du prestataire, le serveur est au nom de ce dernier, et modifier une bannière entraîne des frais supplémentaires.
Ce n'est pas une question de mauvaise foi, c'est que le contrat n'a pas été rédigé clairement. Plus les livrables sont précis, moins il y aura de problèmes par la suite. Voici une décomposition en cinq catégories, chacune accompagnée de formulations que vous pouvez adapter.
1. Code source et package de déploiement : préciser « quoi livrer, comment le livrer »
Le code source est l'élément le plus ambigu. Il est recommandé de préciser trois choses dans le contrat : quels codes sont livrés, sous quelle forme, et si le projet peut fonctionner de manière autonome après la livraison.
Une formulation viable : code source front-end, code source back-end, fichiers de structure de base de données, documentation de déploiement, livrés sous forme de package, avec stipulation que le client peut déployer et faire fonctionner le projet de manière autonome sur son propre serveur après la livraison.
Deux pièges à éviter. Premièrement, mentionner seulement « fourniture du code source » sans préciser la structure de la base de données : même avec le code, le projet ne démarrera pas. Deuxièmement, le code fait référence à des composants privés ou à des fichiers chiffrés créés par le prestataire : la livraison est apparente, mais en réalité on ne peut pas se passer de lui. Les projets de type site web d'entreprise méritent une attention particulière : pour beaucoup de sites à template, le soi-disant code source n'est en fait qu'un encapsulage secondaire sous licence.
S'il s'agit de développement de mini-programme, il faut également préciser : le compte principal du mini-programme appartient au client, et le code peut être soumis au back-office développeur du client.
2. Maquettes et ressources : ne pas se contenter de captures d'écran
Pour les livrables de design, il est recommandé de préciser : les fichiers sources modifiables (Figma, Sketch ou PSD), les ressources découpées, ainsi que les instructions d'utilisation des polices et icônes.
Fournir uniquement des captures JPG revient à ne rien fournir. Lors d'un changement de designer ou pour l'extension de pages événementielles, tout devra être redessiné.
Il faut aussi stipuler la propriété du copyright des ressources : les images, polices et icônes utilisées par le prestataire sont-elles utilisables commercialement, et qui est responsable en cas de litige de droits d'auteur. Ce point est souvent négligé dans les projets de développement web, mais en cas de problème, c'est la mise hors ligne immédiate.
3. Nom de domaine, serveur, comptes : la propriété doit être verrouillée
C'est la zone à haut risque de litiges. Le contrat doit préciser : le nom de domaine est enregistré au nom du client, le serveur ou le compte cloud est acheté sous l'identité réelle du client, et le prestataire ne conserve que les droits d'opération nécessaires pendant le développement et la maintenance.
Un scénario concret : une entreprise refait son site officiel et découvre à la fin que le nom de domaine est entre les mains de l'ancien prestataire ; le renouvellement coûte plus cher, la migration nécessite sa coopération, et le projet est retardé d'un mois.
Il faut donc lister dans la checklist de livraison : le compte de gestion du nom de domaine, le compte du serveur cloud, le compte de la base de données, le compte administrateur du back-office, les informations d'enregistrement ICP, ainsi que les comptes et clés des services tiers (SMS, paiement, cartes). Lors de la remise, vérifier point par point et signer.
4. Back-office et documentation : la livraison n'est effective que si l'on peut l'utiliser
La livraison du système de gestion back-office ne se limite pas au compte : elle inclut également la liste des fonctionnalités, la description des champs, la description des rôles et permissions, et le manuel des opérations courantes.
Il est recommandé de prévoir une formation de passation en ligne ou en présentiel, et d'en conserver l'enregistrement vidéo. Ainsi, en cas de rotation du personnel, les nouveaux collègues pourront se former seuls.
Pour le développement d'App et les projets à back-office complexe, il convient également d'exiger la documentation des API et l'historique des versions, afin de faciliter l'intégration ultérieure avec d'autres systèmes.
5. Critères de recette : transformer « ça marche » en éléments testables
Les clauses de recette doivent être exécutables. Il est recommandé d'écrire : recette fonctionnelle point par point selon le document d'exigences, liste de compatibilité avec les navigateurs et modèles principaux, limite supérieure du temps de chargement des pages, et éléments de base des tests de sécurité web (recherche des injections courantes, des élévations de privilèges, des expositions d'informations sensibles).
Il faut également stipuler la période de correction des défauts, les délais de réponse, ainsi que le nombre de cycles de correction en cas d'échec de la recette.
Piège à éviter : ne pas écrire « sous réserve de satisfaction du client », ni « conforme aux normes du secteur », formulations invérifiables.
Dans quels cas faire appel à MIC Studio
Si vous vous trouvez dans l'une des situations suivantes, vous pouvez envisager de nous contacter : vos besoins sont déjà clairement définis et vous avez besoin d'une checklist de livrables applicable ; un système existant nécessite des tests inversés ou un audit de sécurité ; ou vous n'avez pas de personnel technique dédié en interne, mais vous souhaitez garder la maîtrise des comptes, du code source et de la documentation.
Nous réalisons des sites web d'entreprise, du développement de mini-programmes, du développement d'App et du développement de scripts, et nous assurons également des tests de sécurité. Lors de la phase contractuelle, nous listons les livrables point par point sous forme de tableau, signé en annexe du contrat, afin d'éviter les explications répétées par la suite.
Trois conseils applicables
1. Faire des livrables un tableau annexe, en précisant pour chaque ligne « nom, forme, date de livraison, mode de recette », et le faire signer.
2. Avant la signature, vérifier au nom de qui sont le nom de domaine et le compte cloud ; s'ils ne sont pas au nom du client, procéder à la migration avant de discuter du développement.
3. Lier le pourcentage du solde final à la recette, en conservant 10 % à 20 % à payer après l'achèvement de la formation de passation et la vérification des comptes.
Un contrat détaillé n'est pas un manque de confiance, c'est une façon de faire gagner du temps aux deux parties en évitant les explications.