La demande arrive souvent formulée comme ça : « on voudrait un devis pour refaire notre site ». Quelques questions plus tard, le besoin réel apparaît ailleurs. Le site vitrine existe et il convient. Ce qui bloque, c’est le fichier Excel partagé où quatre commerciaux saisissent leurs visites, les trois versions du même tableau qui circulent par WhatsApp, et les devis retapés à la main dans un modèle Word.
Ce n’est pas un projet de site web, c’est un projet d’application métier. Les deux n’ont ni le même périmètre, ni le même budget, ni le même niveau de risque. Un site vitrine indisponible un dimanche soir est embêtant. Un CRM interne qui perd la saisie de la semaine arrête une équipe commerciale.
Cette confusion de départ fausse le chiffrage avant la première ligne de code, et elle explique une bonne partie des projets qui se terminent en avenants.
Ce que couvre réellement une application web sur mesure
Un site vitrine publie du contenu et collecte des formulaires. Une application web sur mesure fait tourner un processus : des utilisateurs identifiés, des rôles, des données qui changent d’état, et des règles qui décident de ce qui est permis, à qui, et à quel moment. Cette mécanique n’apparaît pas sur une maquette, et c’est pourtant elle qui porte l’essentiel de la charge.
Sur un CRM, un portail client ou une plateforme de réservation, le travail se répartit sur des briques qu’un site vitrine n’a jamais :
- Le modèle de données : client, visite, devis, créneau, facture, leurs liens et leur historique. Une erreur à ce niveau se paie pendant toute la vie de l’outil.
- Les comptes et les droits : un commercial voit ses clients, un responsable voit son équipe, un administrateur corrige. Chaque rôle en plus ajoute des écrans et des tests.
- Les règles et les cas limites : deux clients qui réservent le même créneau à la même seconde, un devis validé puis modifié, une annulation après facturation.
- Les intégrations : logiciel comptable ou ERP, paiement CMI, SMS, e-mail transactionnel, export pour le cabinet comptable.
- L’exploitation : un environnement de test séparé de la production, des sauvegardes dont on a vérifié la restauration, un journal des actions.
- La reprise de l’existant : les années de tableurs à nettoyer, dédoublonner et importer. C’est le poste le plus souvent sous-estimé.
Face à un SaaS, la différence n’est pas technique mais stratégique. Un abonnement vous donne tout de suite 80 % d’un processus standard, avec des limites que vous ne déplacerez pas. Le sur-mesure se justifie quand le processus fait partie de ce qui vous différencie, ou quand une contrainte locale sort du cadre de l’éditeur. Si après discussion votre besoin tient dans une présence en ligne et des formulaires, les repères de budget d’un site web professionnel au Maroc sont d’un tout autre ordre.
Les fourchettes de prix observées au Maroc en 2026
Le coût d’une application web sur mesure au Maroc se construit presque entièrement en jours-homme. Sur le marché local, un jour de développement se situe en général entre 2 500 et 5 000 MAD selon le profil et le type de prestataire, davantage pour un lead technique ou un architecte. Le reste du devis (outillage, licences, hébergement) pèse peu à côté.
Les ordres de grandeur pour un premier périmètre réellement mis en production :
- Outil interne mono-processus (un rôle principal, cinq à huit écrans, saisie, recherche, export) : 60 000 à 150 000 MAD.
- CRM métier ou portail client (plusieurs rôles, documents, notifications, tableau de bord, une intégration) : 150 000 à 400 000 MAD.
- Plateforme de réservation ou de gestion multi-sites (paiement en ligne, facturation, droits fins, intégration ERP) : à partir de 400 000 MAD.
Ce qui fait bouger ces montants n’est pas la technologie choisie mais le nombre de rôles distincts, le nombre d’intégrations avec des systèmes que vous ne contrôlez pas, et l’état des données à reprendre. S’ajoutent l’hébergement, de quelques centaines à quelques milliers de MAD par mois selon la volumétrie, et la maintenance annuelle.
Du cadrage à la mise en production : les délais réels
Le délai de développement d’une application métier se compte en mois, et la part de code pur y est minoritaire. Un découpage courant :
- Cadrage et spécification : 2 à 4 semaines, ateliers avec les utilisateurs et priorisation d’un premier périmètre livrable.
- Conception des écrans et de l’architecture : 1 à 3 semaines, en partie en parallèle.
- Développement par itérations : 6 à 20 semaines, avec une version utilisable montrée toutes les deux semaines.
- Recette et reprise de données : 2 à 5 semaines. C’est là que les plannings glissent.
- Mise en production : une à deux semaines, puis quelques semaines de corrections à chaud.
Comptez 3 à 4 mois pour un outil interne simple, 6 à 9 mois pour un CRM ou un portail client complet. Un facteur compte autant que la méthode du prestataire : la disponibilité d’un référent métier chez vous. Prévoyez l’équivalent de 20 à 30 % du temps d’une personne qui connaît le processus, tranche les arbitrages et teste vraiment. Sans elle, les décisions attendent, et chaque semaine d’attente se retrouve dans le calendrier.
Erreur n°1 : décrire des écrans au lieu de décrire des règles
Le cahier des charges d’une application web ressemble souvent à une liste de pages et d’adjectifs : « tableau de bord moderne », « interface intuitive », « module de réservation ». Un prestataire peut chiffrer ça, mais il chiffre son interprétation, pas votre métier. Les surcoûts arrivent ensuite, le jour où l’on découvre qu’une réservation s’annule jusqu’à 24 heures avant sauf pour les clients sous contrat, et qu’une facture émise ne s’annule pas mais se crédite.
La correction ne demande pas cinquante pages. Écrivez les règles en phrases simples, rôle par rôle : qui crée, qui valide, qui modifie après validation, qui ne doit jamais voir quoi. Puis prenez dix dossiers réels du mois dernier, les deux cas tordus compris, et faites-les passer dans le parcours décrit. Les trous apparaissent en une heure. Le niveau de détail attendu est décrit dans notre guide sur la rédaction d’un cahier des charges IT.
Un chiffrage donné avant toute spécification reste une estimation. Demandez qu’il soit présenté comme telle, hypothèses incluses, et qu’un atelier de cadrage précède l’engagement au forfait.
Erreur n°2 : budgéter le développement et oublier l’après
Une application métier n’est pas livrée, elle est exploitée. Les dépendances se mettent à jour, les navigateurs changent, les utilisateurs réclament le champ qui manque. Prévoyez 15 à 20 % du coût initial par an pour la maintenance corrective et évolutive, hébergement et sauvegardes en plus. Le raisonnement est le même côté mobile, comme détaillé dans notre article sur le budget de maintenance applicative.
L’autre dette se construit pendant le projet. Quand le planning se tend, ce qui disparaît en premier, ce sont les tests automatisés et la documentation. Personne ne le voit à la livraison. On le voit dix-huit mois plus tard, quand une modification de deux heures en demande deux jours parce que plus personne n’ose toucher au module de facturation.
À verrouiller au contrat : la propriété du code et votre accès au dépôt dès le premier sprint, une documentation technique et une procédure de déploiement livrées avec le code, une clause de réversibilité qui décrit ce que vous récupérez si vous changez de prestataire.
SaaS, no-code ou sur-mesure : trancher avant de signer
L’examen commence logiquement par le SaaS. Si votre processus est standard (facturation, support, paie, gestion de projet), un éditeur l’a déjà traité mieux qu’un développement de trois mois. Les raisons valables d’en sortir sont connues : une contrainte de localisation des données, une spécificité locale que l’éditeur ne traitera jamais, un plafond de personnalisation atteint, ou un coût de licences qui dépasse le coût de construction sur trois ans.
Le no-code mérite mieux qu’un haussement d’épaules. Pour un outil interne à cinq ou dix utilisateurs, une base Airtable ou une application Power Apps branchée sur vos données fait souvent le travail en deux semaines, pour quelques centaines de MAD par utilisateur et par mois. Les limites se voient vite : le coût par utilisateur quand l’usage s’étend, puis le mur des règles complexes et des intégrations fines. En prototype, c’est pourtant redoutablement utile, parce que cela valide les règles métier avec les utilisateurs avant qu’on ne les grave dans du code.
Le sur-mesure devient le bon choix quand l’outil porte un avantage concurrentiel, quand il doit s’intégrer profondément à un existant, ou quand le calcul à trois ans licences comprises penche de son côté. Faites ce calcul sur un tableur avant la réunion. Notre comparaison SaaS ou logiciel sur mesure pose les critères plus en détail.
Hébergement des données et conformité CNDP
Dès que l’application stocke des noms, des téléphones, des adresses ou des données RH, elle constitue un traitement de données personnelles au sens de la loi 09-08, avec déclaration auprès de la CNDP. Beaucoup d’entreprises pensent au site web et oublient le CRM interne, qui contient souvent bien plus d’informations sur des personnes identifiables.
À régler pendant le projet, pas après : la déclaration du traitement et sa finalité, l’information des personnes concernées, la limitation des accès par rôle (un stagiaire n’a pas besoin de l’export complet du fichier clients), la journalisation des consultations sensibles, une durée de conservation définie, et la clause de sous-traitance avec votre hébergeur. Si les serveurs sont hors du Maroc, le transfert relève d’un régime particulier : vérifiez les formalités en vigueur sur le site de la CNDP avant d’arrêter la région d’hébergement.
Techniquement, un datacenter marocain comme un cloud européen tiennent sans difficulté la charge d’une application métier de PME. Le choix se fait sur la sensibilité des données, les exigences de vos propres clients et la latence. Les obligations déclaratives sont détaillées dans notre article sur la conformité CNDP.
Ce qui doit figurer dans le devis
- Un périmètre en lots chiffrés séparément, avec le nombre de jours par profil. Un forfait global sur une seule ligne n’est comparable à rien.
- Les hypothèses écrites : nombre de rôles, nombre d’intégrations, volume de données reprises, qui fournit les accès.
- La reprise de données chiffrée à part, en précisant qui nettoie les doublons.
- Les critères de recette et le délai de correction des anomalies bloquantes.
- La maintenance : périmètre, prix annuel, temps de réponse, ce qui en est exclu.
- La propriété du code, l’accès au dépôt et aux environnements, les comptes ouverts à votre nom.
- La formation des utilisateurs finaux et un support de prise en main.
Un devis chiffré en 48 heures, sans aucun atelier, pour un outil censé porter votre processus commercial, repose forcément sur des hypothèses que personne n’a écrites. Demandez-les. La réponse renseigne plus que le montant.
Cadrer d’abord
La séquence utile est presque toujours la même : clarifier le processus, écrire les règles, décider entre SaaS, no-code et sur-mesure, puis chiffrer un premier périmètre réduit qui part en production en quelques mois au lieu d’un projet complet promis dans un an. Arrowlancer conçoit et développe des applications web métier pour des PME marocaines, CRM, portails clients et plateformes de réservation, dans la continuité de nos prestations web. Si vous avez un besoin à cadrer ou un devis à challenger, écrivez-nous : une heure de discussion suffit souvent à dire si le sur-mesure se justifie.