Vous venez de mettre en production une plateforme métier sur mesure. Le budget développement est dépensé, l'équipe projet est dissoute, et trois jours plus tard votre directeur commercial signale qu'un filtre de recherche ne renvoie aucun résultat. Vous appelez le prestataire. Il vous répond : « Ce n'est pas un bug, c'est une évolution. » Facture : 6 000 MAD.
Cette scène se répète dans toutes les grandes entreprises qui font développer des applications métier. Le vrai problème n'est pas le montant, c'est l'absence de règle. La frontière entre correction (gratuite pendant la garantie) et évolution (payante dès le premier jour) n'est presque jamais définie par écrit au contrat. Le budget ne fuit pas sur les gros chantiers, il fuit sur cette ligne floue, demande après demande, dans une négociation permanente qui use les deux parties.
Cet article donne la définition d'anomalie à inscrire au contrat, la troisième catégorie que tout le monde oublie (l'adaptation réglementaire), et le mécanisme qui règle le problème pour de bon : un catalogue de demandes types tarifé à l'avance, qui transforme la bagarre sur les avenants en question de transparence tarifaire.
Correctif, évolutif, réglementaire : trois budgets, trois logiques
La confusion vient d'abord du vocabulaire. Les entreprises parlent de « maintenance », mais ce mot cache en réalité trois prestations distinctes, qui ne mobilisent ni le même budget, ni le même circuit de décision.
La maintenance corrective répare ce qui ne marche pas comme spécifié. Un export qui génère un fichier vide alors que le cahier des charges prévoit un CSV avec toutes les lignes, un calcul de provision qui affiche un résultat faux, une notification qui ne part jamais : ce sont des anomalies. Elles relèvent de la garantie post-mise en production et doivent être corrigées gratuitement pendant une période contractuelle (généralement 3 à 12 mois). Budget : zéro, c'est inclus dans le forfait initial de développement.
La maintenance évolutive ajoute ce qui n'existait pas dans le périmètre validé. Votre équipe veut un nouveau filtre de recherche par fournisseur étranger ? Votre direction souhaite un tableau de bord avec des graphiques de suivi trimestriel ? Ce sont des évolutions. Elles sont toujours payantes, même le premier jour, car elles n'ont jamais fait partie du contrat d'origine. Budget : variable, souvent entre 50 000 et 500 000 MAD par an selon l'intensité d'usage de la plateforme.
L'adaptation réglementaire couvre les modifications imposées par un changement de loi ou de norme. Nouvelle obligation de déclaration TVA, modification du format CNSS pour les imports de masse salariale, adoption d'un nouveau référentiel comptable : personne n'a demandé ces changements, mais l'application doit s'y conformer sous peine d'être inutilisable. Cette catégorie n'est ni un bug (le code fait bien ce qu'on lui a demandé) ni une envie (vous n'avez pas choisi la nouvelle règle). Budget : à négocier au cas par cas, certains contrats prévoient une enveloppe annuelle dédiée.
La plupart des contrats ne mentionnent que « maintenance corrective » et « maintenance évolutive ». Résultat : dès qu'une administration publie un nouveau décret, la même discussion recommence. Le prestataire dit « c'est une évolution », le client dit « je ne l'ai pas demandée, donc c'est un bug », et on négocie un avenant ad hoc qui retarde le chantier de trois semaines.
La définition d'une anomalie : le seul paragraphe qui compte vraiment
Voici la phrase qui manque dans 80 % des contrats que nous avons audités ces trois dernières années :
Est réputée anomalie toute différence mesurable entre le comportement observé de l'application et le comportement décrit dans les spécifications fonctionnelles validées par les deux parties avant le début du développement, ou tout dysfonctionnement technique qui empêche l'utilisation normale de l'application.
Cette définition établit deux critères objectifs. Premier critère : une trace écrite. Le comportement attendu doit figurer dans un document signé (cahier des charges, user story validée, procès-verbal de recette). Si votre demande n'a jamais été documentée, ce n'est pas un bug, c'est une nouvelle demande. Deuxième critère : une mesure. Le champ affiche « 0 » au lieu de « 12 345 » ? Anomalie. L'export génère 0 ligne au lieu de 200 ? Anomalie. Le temps de réponse atteint 45 secondes au lieu de moins de 3 ? Anomalie, si le contrat spécifiait un engagement de performance.
En pratique, cela signifie aussi que tout ce qui n'était pas écrit n'est pas garanti. Vous pensiez que l'application devait trier les fournisseurs par ordre alphabétique, mais rien ne le dit dans les specs ? Le prestataire a livré un tri chronologique (date d'ajout). Ce n'est pas un bug, c'est un malentendu. La correction sera facturée.
C'est brutal, mais c'est la seule règle qui arrête les débats sans fin. Elle oblige les deux parties à écrire précisément ce qui sera fait avant de commencer, ce qui améliore la qualité du cahier des charges et réduit les surprises à la recette.
La définition doit également couvrir les dysfonctionnements techniques : une page qui renvoie une erreur 500, une base de données qui sature et bloque toute connexion, un service qui tombe en panne tous les matins à 9h. Ces cas ne figurent jamais dans les specs fonctionnelles (personne n'écrit « la page d'accueil doit s'afficher sans erreur »), mais ils relèvent évidemment de la garantie. Le contrat doit donc ajouter une clause fourre-tout pour les pannes, les crashs, et toute indisponibilité non programmée.
Ce que couvre la garantie après mise en production, et où elle s'arrête
La garantie légale au Maroc court 12 mois pour les logiciels (Code des Obligations et Contrats, art. 555). En pratique, les contrats de développement sur mesure prévoient souvent une garantie conventionnelle plus courte (3 à 6 mois) ou plus longue (jusqu'à 24 mois pour les plateformes critiques), selon le rapport de force commercial.
Pendant cette période, le prestataire corrige gratuitement toutes les anomalies au sens de la définition ci-dessus. Gratuitement signifie : pas de facturation du temps passé, mais avec un délai d'intervention qui dépend de la gravité. Les contrats bien rédigés établissent une grille de criticité :
- Critique (P1) : l'application est totalement inutilisable (page d'erreur générale, base de données inaccessible). Intervention sous 4 heures ouvrées, résolution sous 24h.
- Majeure (P2) : une fonction clé ne marche pas (impossible de créer un nouveau dossier fournisseur, export mensuel bloqué). Intervention sous 1 jour ouvré, résolution sous 5 jours.
- Mineure (P3) : un détail d'interface, une coquille dans un libellé, un alignement de colonne. Intervention sous 5 jours, résolution sous 15 jours ou lors de la prochaine release.
Sans grille, vous obtenez « on le regarde dès que possible », ce qui peut signifier trois mois pour une correction cosmétique de footer. Avec la grille, vous pouvez suivre contractuellement. Si le prestataire dépasse les délais P1 trois fois en un trimestre, c'est un motif de pénalité ou de rupture.
La garantie ne couvre pas :
- Les évolutions fonctionnelles demandées après la recette, même si elles paraissent évidentes à vos utilisateurs.
- Les adaptations réglementaires ou techniques (nouvelle version de navigateur, migration de serveur, nouvelle API bancaire imposée par votre organisme).
- Les erreurs causées par une mauvaise utilisation de l'application (suppression manuelle de lignes en base, import d'un fichier dans un format différent de celui documenté).
- Les demandes de formation ou de support utilisateur au-delà d'un quota initial (souvent 2 à 4 jours de formation inclus, puis payant).
Ces exclusions doivent figurer explicitement au contrat. Sinon, la clause « toute anomalie sera corrigée gratuitement » devient élastique : le client estime que tout défaut relève de la garantie, le prestataire facture tout ce qu'il peut. Résultat : une négociation sur chaque ticket, qui consomme plus de temps que la correction elle-même.
L'abonnement de maintenance : qu'achète-t-on exactement pour un montant mensuel récurrent
Après la garantie, la plupart des entreprises souscrivent un contrat de maintenance annuel, généralement facturé 12 à 20 % du coût de développement initial par an. Pour une plateforme livrée à 800 000 MAD, attendez-vous à payer entre 96 000 et 160 000 MAD par an. Mais que couvre réellement ce montant ?
Le socle minimum inclut toujours :
- Support technique : une hotline ou un canal e-mail dédié pour signaler les anomalies, avec engagement de délai de première réponse (souvent 4h à 48h selon la criticité).
- Correction des bugs résiduels : toute anomalie découverte après la fin de la garantie initiale est corrigée sans facturation additionnelle du temps passé, dans la limite d'un quota (par exemple 10 jours-homme par an).
- Mises à jour de sécurité : patches critiques pour le framework utilisé (Laravel, Symfony, React), mise à jour de bibliothèques tierces présentant des vulnérabilités CVE.
- Hébergement et monitoring : selon les contrats, peut inclure l'infra serveur, les sauvegardes automatiques, et une surveillance 24/7 des temps de réponse.
Ce que la maintenance n'inclut jamais par défaut :
- Les évolutions fonctionnelles. Un nouvel écran, un nouveau rapport, une nouvelle intégration API : toujours en supplément.
- Les adaptations réglementaires. Une nouvelle obligation fiscale qui nécessite un nouvel export : facturé en sus ou via une enveloppe séparée.
- Les migrations techniques majeures (changement de version PHP, migration cloud, refonte de la base de données).
Le piège classique : vous payez 120 000 MAD par an de maintenance, et au bout de six mois vous découvrez que ce montant n'a payé que le support et l'hébergement. Toute demande d'évolution déclenche une facturation additionnelle, et vous finissez à 300 000 MAD en année pleine.
Pour éviter cette dérive, certains contrats prévoient une enveloppe d'évolutions incluse dans l'abonnement annuel. Par exemple : 120 000 MAD par an comprenant le support + 5 jours-homme d'évolutions à consommer librement. Au-delà de 5 jours, facturation au jour (tarif souvent entre 8 000 et 12 000 MAD/jour pour un développeur senior). Cette formule donne de la visibilité et évite les surprises, à condition que le décompte soit transparent (un ticket de suivi pour chaque heure consommée).
Le catalogue de demandes types tarifé à l'avance, plutôt que la négociation au fil de l'eau
Le vrai problème avec la maintenance évolutive, c'est que chaque demande déclenche une négociation. Vous voulez ajouter un filtre de recherche par région ? Le prestataire vous envoie un devis : 15 000 MAD. Vous trouvez ça cher pour « juste un menu déroulant ». Échange de trois e-mails, réunion téléphonique, renégociation à 12 000 MAD. Délai pour avoir le filtre : cinq semaines, dont quatre passées à discuter du prix.
La solution qui fonctionne dans les relations de long terme (abonnement pluriannuel, plateforme vivante avec 20 à 40 demandes par an) : un catalogue de demandes types tarifé à l'avance, annexé au contrat de maintenance.
Exemple de catalogue pour une plateforme de gestion de fournisseurs :
| Demande type | Effort (j/h) | Prix unitaire (MAD HT) |
|---|---|---|
| Ajout d'un champ texte ou numérique sur un formulaire existant | 0,5 j/h | 4 000 |
| Ajout d'un filtre de recherche (liste déroulante) | 1 j/h | 8 000 |
| Création d'un nouvel export Excel (colonnes standard) | 1,5 j/h | 12 000 |
| Ajout d'une notification e-mail automatique | 2 j/h | 16 000 |
| Création d'un nouveau rôle utilisateur avec droits spécifiques | 3 j/h | 24 000 |
| Intégration API tierce (webhook entrant ou sortant) | Sur devis | Minimum 40 000 |
Avec ce catalogue, la discussion change. Vous ne négociez plus le prix de chaque demande, vous vérifiez qu'elle rentre dans une case du catalogue. Si oui, vous commandez, c'est tarifé. Si la demande est plus complexe ou sort du catalogue, elle passe en « sur devis », mais au moins 70 % des demandes courantes sont couvertes.
Cela donne de la prévisibilité budgétaire : vous savez qu'un nouveau champ coûte 4 000 MAD, donc avant de demander, vous vérifiez si c'est prioritaire. Ça donne aussi de la vitesse : plus de négociation, le prestataire commence dès réception du bon de commande.
Le catalogue doit être révisé annuellement : les tarifs peuvent augmenter (inflation, hausse des compétences techniques requises), et de nouvelles catégories apparaissent avec l'usage. Après deux ans, vous aurez peut-être besoin d'un tarif pour « ajout d'un graphique sur tableau de bord » ou « modification de workflow de validation ». Ajoutez-les au catalogue lors du renouvellement.
Quand la réglementation change en cours de contrat, qui paie l'adaptation
Un décret fiscal oblige désormais les entreprises à transmettre mensuellement un fichier XML de déclaration TVA au portail SIMPL. Votre ERP ne génère pas ce format. Qui paie les 60 000 MAD de développement pour ajouter l'export ?
Juridiquement, si le contrat initial ne prévoyait pas cette fonctionnalité (parce que l'obligation n'existait pas à la date de signature), c'est une évolution. Le prestataire n'a aucune obligation de la livrer gratuitement. En pratique, la réponse dépend de la clause d'adaptation réglementaire :
- Option 1 : payant en sus, au réel. Toute modification imposée par la loi est facturée au temps passé. Simple, mais coûteux si trois décrets sortent la même année.
- Option 2 : enveloppe annuelle forfaitaire. Le contrat de maintenance inclut 20 000 MAD par an pour les adaptations réglementaires. Si rien ne change, vous ne consommez rien. Si un gros chantier survient, vous avez un tampon. Au-delà de l'enveloppe, facturation en sus.
- Option 3 : refacturation au client final. Applicable dans certains métiers où le logiciel est revendu à des clients finaux (éditeur SaaS, intégrateur). Le coût de l'adaptation est amorti sur l'ensemble de la base clients et inclus dans l'abonnement. Pas applicable pour du développement sur mesure en interne.
Notre recommandation : l'option 2 est la plus équilibrée. Vous provisionnez un budget réglementaire sans en payer le coût tous les ans, et le prestataire sait qu'il a une enveloppe à consommer avant de facturer du surplus. En revanche, fixez une règle claire pour qualifier une demande de « réglementaire » : elle doit être causée par une obligation légale ou réglementaire externe publiée au Bulletin Officiel, par une mise à jour de norme bancaire ou comptable imposée par la profession, ou par une évolution d'API tierce hors contrôle des deux parties. Une « bonne pratique » ou une « recommandation de l'auditeur » ne qualifie pas.
Le tableau de répartition à faire signer avant la mise en production
La meilleure façon d'éviter les litiges, c'est de clarifier les règles avant la recette finale. Voici le tableau à annexer au contrat, à remplir avec le prestataire, et à faire valider par votre direction des achats ou votre DAF avant de signer le PV de mise en production :
| Type de demande | Qui paie ? | Délai d'intervention | Budget annuel estimé |
|---|---|---|---|
| Anomalie bloquante (P1) | Prestataire (garantie) | 4h / résolution 24h | 0 (inclus) |
| Anomalie majeure (P2) | Prestataire (garantie) | 1j / résolution 5j | 0 (inclus) |
| Anomalie mineure (P3) | Prestataire (garantie) | 5j / résolution 15j | 0 (inclus) |
| Évolution fonctionnelle (nouveau champ, filtre) | Client (catalogue tarifé) | Variable selon catalogue | 80 000 à 150 000 MAD |
| Évolution structurante (nouveau module) | Client (devis sur mesure) | Selon devis | À définir |
| Adaptation réglementaire | Enveloppe dédiée 30 000 MAD/an | Selon criticité | 30 000 MAD |
| Support utilisateur et formation | 2 jours inclus, puis 6 000 MAD/jour | Sur RDV | 24 000 à 48 000 MAD |
| Hébergement, sauvegardes, monitoring | Abonnement mensuel | 24/7 | 60 000 à 120 000 MAD |
Ce tableau donne de la visibilité aux deux parties. Votre DSI sait qu'il doit provisionner entre 170 000 et 350 000 MAD par an post-production. Le prestataire sait qu'il ne sera pas sollicité gratuitement pour tout et n'importe quoi. Les achats savent qu'ils doivent budgétiser un contrat cadre maintenance avec des bons de commande évolutifs.
Signez ce tableau avec le contrat de développement initial, pas six mois après la mise en production. À ce moment-là, vous êtes déjà en conflit sur trois tickets, et il est trop tard pour clarifier les règles.
FAQ
Un bug découvert 18 mois après la mise en production est-il encore couvert par la garantie ?
Non, sauf si votre contrat prévoit une garantie pluriannuelle (rare). La garantie légale court 12 mois maximum au Maroc. Après ce délai, même une anomalie objective relève du contrat de maintenance : elle sera corrigée, mais dans le cadre du quota de jours inclus dans l'abonnement annuel, ou en supplément si le quota est dépassé. En revanche, si le bug existait déjà pendant la garantie et que vous l'avez signalé avant la fin de période (avec preuve écrite), le prestataire doit le corriger gratuitement, même si la correction intervient après expiration du délai.
Le prestataire peut-il refuser de corriger un bug en arguant qu'il était présent lors de la recette ?
Oui, si vous avez signé le procès-verbal de recette sans réserve. La signature du PV de recette vaut acceptation de l'application dans l'état testé. Si un dysfonctionnement était visible et que vous ne l'avez pas signalé, le prestataire peut considérer que vous l'avez accepté. C'est pour cela que la phase de recette doit être exhaustive : testez tous les scénarios critiques avant de signer. Certains contrats prévoient une période de « garantie élargie » de 30 à 60 jours après la recette, pendant laquelle les anomalies découvertes en production réelle restent couvertes même si elles n'ont pas été testées lors de la recette formelle.
Comment éviter que le prestataire ne surestime le temps nécessaire pour une petite évolution ?
Deux mécanismes : le catalogue tarifé (évoqué plus haut) et la transparence du décompte horaire. Exigez contractuellement un suivi détaillé du temps passé sur chaque ticket (via un outil de ticketing comme Jira, ClickUp, ou un simple fichier partagé), avec une description des tâches réalisées. Si une demande cataloguée à 1 jour consomme systématiquement 3 jours, soit le catalogue est sous-évalué (à réviser), soit l'efficacité du prestataire est un problème. Un audit technique par un tiers (cabinet de conseil ou CTO freelance) peut objectiver le débat et éviter les soupçons permanents.
Doit-on payer la maintenance même si on n'a aucune demande d'évolution pendant un an ?
Oui, si vous avez signé un contrat de maintenance à l'année. L'abonnement couvre le support, l'hébergement, le monitoring, les mises à jour de sécurité, et la disponibilité du prestataire pour intervenir en cas de panne. Même sans évolution, ces services ont un coût. Certains contrats proposent une formule « à la demande » (facturation au ticket), mais elle est toujours plus chère à l'unité (10 000 à 15 000 MAD/jour au lieu de 8 000 MAD en abonnement) et ne garantit pas de délai d'intervention. Réservez cette formule aux applications peu critiques que vous n'utilisez que quelques mois par an.
Que faire si le prestataire initial a fermé ou n'est plus joignable ?
C'est le risque de dépendance technique. Votre contrat doit prévoir une clause de séquestre de code : le prestataire dépose régulièrement (tous les 3 à 6 mois) une copie du code source et de la documentation technique chez un tiers de confiance (avocat, séquestre agréé, plateforme d'escrow). En cas de défaillance du prestataire, vous récupérez le code et pouvez faire reprendre la maintenance par un autre prestataire. Sans clause de séquestre, vous êtes bloqué : soit vous payez un audit reverse-engineering (entre 50 000 et 150 000 MAD pour reconstituer la doc), soit vous redéveloppez tout. Certains grands comptes exigent aussi la formation d'une équipe interne pendant le projet, pour réduire la dépendance et permettre une reprise en main progressive.
Pour approfondir la structuration de vos contrats de développement et de maintenance, consultez nos guides sur la transformation digitale et le conseil en architecture logicielle. Si vous gérez plusieurs applications métier et souhaitez un audit de vos contrats existants, notre équipe analyse les clauses critiques et vous propose un plan d'optimisation budgétaire sur trois ans : applications métier sur mesure.