Agence web à Marrakech : 12 livrables à vérifier avant de signer
Une checklist d’achat pour comparer les offres d’agence web à Marrakech sur le périmètre, les tests, la propriété et la maintenance.
Une agence web à Marrakech ne devrait pas être évaluée seulement sur un prix, une maquette ou une liste de technologies. Avant de signer, le devis doit rendre le projet vérifiable : objectifs, périmètre, responsabilités, critères de recette, propriété des accès et conditions de maintenance. Cette grille aide une PME, un hôtel, une association ou une équipe métier à comparer des propositions qui paraissent proches mais ne couvrent pas toujours les mêmes obligations.
La réponse courte est simple : exigez douze livrables écrits avant le démarrage. Ils ne garantissent pas le succès, mais ils réduisent les zones grises et donnent à chaque décision une preuve attendue.
Pourquoi le prix seul ne permet pas de comparer deux devis
Deux propositions peuvent annoncer un « site professionnel » tout en recouvrant des réalités différentes. L’une inclut la recherche utilisateur, le contenu multilingue, les tests et la documentation ; l’autre limite sa prestation à l’intégration de quelques pages. Le coût n’est comparable que lorsque le périmètre, la qualité attendue et les responsabilités sont décrits de la même manière.
Les résultats de recherche actuels pour les requêtes liées à une agence web à Marrakech mettent souvent en avant des forfaits, des délais et des demandes de devis. L’espace éditorial utile consiste donc à détailler les éléments permettant d’évaluer ces offres sans transformer une promesse commerciale en garantie.
1. Une note de cadrage avec objectifs et critères de succès
Le premier livrable doit expliquer le problème métier, les publics, les parcours prioritaires et les contraintes connues. Un objectif comme « moderniser le site » reste trop vague. Demandez plutôt quelles actions doivent devenir plus claires : demander un devis, réserver, déposer un document, consulter un service ou contacter une équipe.
Les critères de succès doivent préciser ce qui sera observé après la mise en ligne, sans promettre un chiffre avant d’avoir une référence. La note peut distinguer les indicateurs de produit, de qualité technique et d’exploitation.
2. Un périmètre fonctionnel et des parcours validés
Le périmètre liste les pages, fonctionnalités, rôles utilisateurs, langues et exclusions. Il doit aussi décrire les cas limites : erreur de paiement, formulaire incomplet, fichier refusé, session expirée ou demande transmise à un humain. Un schéma de parcours ou un prototype permet de vérifier cette compréhension avant le développement.
Pour une application ou un portail, reliez ce livrable au service Web & Mobile de Kanteek et, si le projet reste incertain, à une mission de Conseil & Stratégie.
3. Un inventaire des contenus et des responsabilités
Textes, images, traductions, mentions légales, fiches produits et données ne doivent pas apparaître à la dernière minute. Le devis doit dire qui fournit, relit, traduit, migre et valide chaque contenu. Pour un site français, anglais et arabe, précisez aussi les adaptations éditoriales et l’affichage de droite à gauche, au lieu de prévoir une simple traduction littérale.
L’inventaire identifie les contenus existants à conserver, fusionner, rediriger ou supprimer. Il prépare aussi le maillage interne et évite de créer plusieurs pages concurrentes sur la même intention.
4. Un prototype UX et un système de composants
Les écrans clés doivent être validés avant leur multiplication. Exigez un prototype des parcours prioritaires, les états d’erreur, les variantes mobiles et les règles de navigation. La livraison peut inclure une bibliothèque de composants, ses comportements et ses contraintes d’usage.
Un design system pour le web et le mobile facilite la cohérence, la maintenance et les tests. Il ne s’agit pas d’une galerie décorative : chaque composant doit documenter contenu, états, accessibilité et responsive design.
5. Une architecture technique et une carte des intégrations
Le document d’architecture nomme l’hébergement, le CMS ou framework, la base de données, les API, les services tiers et les environnements. Il indique où circulent les données, quelles dépendances sont critiques et qui possède chaque compte.
Demandez aussi les hypothèses : volume attendu, fréquence de mise à jour, besoins hors ligne, stockage des médias, compatibilité avec les outils existants et contraintes de localisation des données. Une agence web à Marrakech doit pouvoir expliquer ces choix dans un langage décisionnel, pas seulement citer une stack.
6. Une cible d’accessibilité vérifiable
Le W3C recommande WCAG 2.2 comme référence actuelle. Si le devis annonce un niveau de conformité, exigez le périmètre de pages, la méthode de test, les navigateurs et technologies d’assistance couverts, ainsi que le format du rapport. Une déclaration générale « accessible » ne remplace pas des critères de recette.
Pour préparer ces critères, consultez le guide Kanteek sur l’accessibilité numérique au Maroc.
7. Un budget de performance et des mesures terrain
La performance doit être exprimée par des métriques et une méthode. Les Core Web Vitals documentés par Google couvrent notamment le chargement, l’interactivité et la stabilité visuelle. Le devis doit préciser ce qui sera mesuré en laboratoire, ce qui dépendra de données réelles et comment les régressions seront surveillées.
Un objectif ne vaut que pour un périmètre, des pages, des appareils et des conditions définis. Les tests de charge en production complètent cette approche lorsqu’un service doit absorber des usages simultanés.
8. Un socle SEO technique et éditorial
Le livrable SEO doit couvrir les URL, balises, titres, données structurées réellement visibles, sitemap, robots, redirections, hreflang et maillage interne. Les Google Search Essentials rappellent qu’une page doit être accessible techniquement et proposer un contenu utile ; respecter ces pratiques ne garantit ni indexation ni position.
Demandez également qui fournit la recherche de mots-clés, la carte des intentions et les contenus. Une simple installation d’extension SEO ne constitue pas une stratégie.
9. Des exigences de sécurité et une preuve de vérification
Pour une application, un portail ou un site avec données sensibles, la sécurité doit devenir un ensemble de contrôles testables. L’OWASP Application Security Verification Standard fournit une base pour spécifier et vérifier des exigences de sécurité web, y compris dans un contexte d’achat.
Le devis peut définir l’authentification, les autorisations, la gestion des secrets, les dépendances, la journalisation et la correction des vulnérabilités. Le guide sur le DevSecOps au Maroc aide à relier ces contrôles au processus de livraison.
10. Un plan de tests et une recette formelle
Le plan de recette traduit chaque exigence en preuve : scénario, résultat attendu, environnement, responsable et statut. Il couvre fonctions, contenus, langues, mobile, navigateurs, accessibilité, performance, sécurité et intégrations selon le risque réel.
Précisez le nombre de cycles de correction, les règles de priorité et ce qui constitue une acceptation. Sans cette définition, « terminé » peut signifier intégré pour l’agence et validé en production pour le client.
11. Un plan de mise en production, d’accès et de propriété
Avant la mise en ligne, listez les domaines, DNS, hébergement, dépôts de code, comptes analytics, outils publicitaires, adresses email et certificats. Le client doit savoir qui est propriétaire, qui administre et comment les accès sont transférés ou révoqués.
Le plan doit prévoir sauvegarde, restauration, redirection, fenêtre de déploiement, suivi des erreurs et solution de retour arrière adaptée au projet.
12. Une documentation de maintenance et de réversibilité
La livraison finale doit expliquer comment publier un contenu, déployer une version, surveiller le service, traiter un incident et demander une évolution. Le contrat précise les délais de prise en charge, les exclusions, les mises à jour et le coût des travaux hors périmètre.
La réversibilité décrit ce qui sera remis en cas de changement de prestataire : code, export des données, documentation, comptes, licences et état des dépendances. C’est un critère de continuité, pas un signal de défiance.
Forfait ou régie : quelle forme de devis choisir ?
Le forfait convient à un périmètre stable, avec critères de recette et procédure de changement. La régie convient mieux à l’exploration ou à un produit qui évolue par cycles. Un modèle hybride peut isoler une phase de cadrage, puis chiffrer un lot validé. Le bon choix dépend de l’incertitude, pas d’une préférence universelle.
Questions à poser à une agence web à Marrakech
- Quels livrables sont inclus, exclus ou dépendants du client ?
- Comment validez-vous les parcours, les contenus et les trois langues ?
- Quels critères rendent la recette objective ?
- Qui possède le domaine, l’hébergement, le dépôt et les comptes tiers ?
- Quelles mesures de performance, d’accessibilité et de sécurité seront remises ?
- Que se passe-t-il après la garantie ou en cas de changement de prestataire ?
Une réponse précise permet de comparer les propositions sur leur substance. Pour cadrer votre propre projet, présentez vos objectifs et contraintes à Kanteek avant de demander un chiffrage.
FAQ
Que doit contenir le devis d’une agence web à Marrakech ?
Il doit contenir le périmètre fonctionnel, les contenus, les prototypes, l’architecture, les critères de qualité, le plan de tests, la mise en production, les droits d’accès, la maintenance et la réversibilité. Les exclusions et responsabilités du client doivent être aussi visibles que les éléments inclus.
Faut-il demander un prix avant le cahier des charges ?
Une enveloppe peut orienter les choix, mais un prix ferme n’est comparable qu’après définition d’un périmètre minimal. Une courte phase de cadrage peut éviter de chiffrer des hypothèses incompatibles.
Comment vérifier une promesse de SEO ou de performance ?
Demandez la métrique, l’outil, l’environnement, la période et le seuil d’acceptation. Pour le SEO, aucune agence ne peut garantir une position ; elle peut en revanche livrer une architecture indexable, un contenu utile et un protocole de mesure.
