Quel type de site web votre entreprise a-t-elle vraiment besoin ?
La plupart des projets web commencent par une plateforme et reculent ensuite vers les besoins. C'est l'ordre inverse du bon, et c'est pourquoi tant d'entreprises paient l'entretien de fonctions qu'elles n'utilisent jamais. Ce guide commence là où la décision se prend réellement : ce qui doit arriver, pour qui, et à quelle fréquence.
La réponse courte
Votre site doit avoir la forme qui permet à ce dont votre entreprise a besoin d'arriver — et rien de plus. Pour la majorité des entreprises, c'est un site de génération de clients : des pages qui expliquent l'offre, des formulaires qui se rendent réellement à une personne, et une mesure qui montre quelles pages produisent des demandes. Une boutique transactionnelle, un moteur de réservation, des comptes clients, un portail ou une application ne se justifient que lorsqu'un vrai processus d'affaires ne peut pas fonctionner sans. Tout le reste ajoute un coût permanent : sécurité, tests, hébergement, mises à jour, formation, entretien. Une fonctionnalité doit exister parce qu'elle crée de la valeur, pas parce qu'elle est réalisable.
Les besoins avant la technologie
Cette décision a une séquence, et chaque étage découle du précédent. Choisir WordPress, Shopify, Framer, Next.js ou Supabase avant d'avoir descendu cette liste inverse le processus : on s'engage d'abord dans une série de contraintes, puis on découvre ce dont l'entreprise avait besoin.
01
Objectif d'affaires
Le résultat commercial, chiffré si vous l'avez. Plus de demandes qualifiées. Moins d'appels sur les disponibilités. Des commandes qui n'exigent personne pour être traitées.
↓
02
Action du visiteur
La seule chose qu'un visiteur doit faire pour que ce résultat se produise. Envoyer une demande. Passer une commande. Réserver une plage horaire. Se connecter et télécharger un document.
↓
03
Fonctionnalités
Ce qui doit exister pour rendre cette action possible. Un formulaire qui valide et qui se rend. Un panier qui survit à un rechargement. Un calendrier qui ne peut pas doubler une réservation.
↓
04
Contenu
Ce qui doit se trouver sur la page pour qu'on passe à l'action, en quelle quantité, et à quelle fréquence ça change. C'est ici que la question du CMS se tranche — pas plus tard.
↓
05
Intégrations
Où les données doivent aller ensuite. Un CRM, la comptabilité, l'inventaire, un logiciel de réservation, une plateforme de courriels. Tout ce que l'entreprise utilise déjà et ne laissera pas tomber.
↓
06
Administration
Qui modifie quoi, qui approuve, et ce que personne ne doit pouvoir briser. Aussi : qui répond quand ça casse un vendredi à 19 h.
↓
07
Sécurité et données
Quelles données personnelles ou de paiement sont recueillies, où elles résident, qui peut y accéder. Au Québec, ce n'est pas une réflexion technique : la Loi 25 en fait une obligation documentée dès le premier compte client.
↓
08
Croissance
Ce qui cède à dix fois le trafic, dix fois le catalogue ou dix fois les utilisateurs — et si c'est une année réaliste ou un trimestre imaginaire.
↓
09
Technologie
Seulement maintenant. La pile technologique découle des huit réponses précédentes ; si deux plateformes y répondent également, le choix entre elles n'est pas la décision importante.
Si quelqu'un vous propose une plateforme avant de vous avoir posé au moins les cinq premières questions, il vend ce qu'il construit déjà. Ça peut rester la bonne réponse — ce n'est simplement pas encore un argument.
Cochez tout ce qui est vrai pour votre entreprise. Rien n'est enregistré, rien n'est envoyé, et le résultat se met à jour au fur et à mesure. L'important n'est pas la recommandation finale : c'est que chaque énoncé change le projet d'une façon précise, et que vous voyiez lesquels vous êtes en train de choisir.
Les neuf types
Presque tous les sites d'entreprise sont l'un de ceux-ci, ou une combinaison assumée de deux. Ils sont décrits par ce qu'ils exigent plutôt que par ce qui les propulse, parce que ce sont les exigences que vous vous engagez à porter.
Site vitrineProuver que l'entreprise est réelle, compétente et joignable.＋
Quand c'est suffisant
Le travail arrive par référence, par téléphone ou en personne, et le site sert à confirmer que vous existez et que ça vaut la peine d'appeler. C'est une réponse légitime, pas une version d'entrée de gamme — un site de cinq pages rapide et bien écrit bat un site de vingt pages négligé, à tout coup.
Ce que ça exige réellement
—Des services clairs, de vraies preuves de travail, de vraies coordonnées
—Un chargement rapide et une mise en page qui tient sur un téléphone
—Des informations d'entreprise exactes partout où elles apparaissent en ligne
L'erreur coûteuse
Ajouter un blogue que personne n'écrira, une boutique sans produits et un module de réservation pour une entreprise qui réserve par texto — puis payer l'entretien des trois.
Site de génération de clientsTransformer le trafic en demandes qu'on peut attribuer et mesurer.＋
Quand c'est suffisant
La vente se conclut dans une conversation, pas dans une caisse — services professionnels, métiers, cabinets, consultants, B2B. C'est ce dont la majorité des entreprises ont réellement besoin, et là où un budget web rapporte le plus.
Ce que ça exige réellement
—Une page par service, écrite pour être trouvée et pour répondre aux objections
—Des formulaires qui valident, se rendent à une personne et résistent aux pourriels
—Une mesure qui attribue les demandes aux pages
—Un endroit où la demande atterrit et fait l'objet d'un suivi
L'erreur coûteuse
Mesurer le trafic au lieu des demandes. Une page qui se classe et ne convertit personne est un centre de coûts avec une belle posture.
Site de contenu / SEOGagner du trafic en continu en occupant les questions que vos acheteurs posent.＋
Quand c'est suffisant
Votre marché cherche avant d'acheter, et vous pouvez vous engager à publier pendant un an plutôt qu'un trimestre. Sans cet engagement, c'est la façon la plus chère de posséder des archives vides.
Ce que ça exige réellement
—Une architecture de contenu : une page par intention, reliée délibérément
—Un CMS que quelqu'un utilisera vraiment, avec des types de contenu structurés
—Des données structurées, des URL propres et un plan de site qui reste exact
—Un rythme de publication, et une personne dont c'est la tâche
L'erreur coûteuse
Publier du volume au lieu de la couverture. Cinquante articles minces se nuisent entre eux ; dix pages qui répondent réellement à une question, non.
Site transactionnelVendre des produits sans qu'une personne traite la transaction.＋
Quand c'est suffisant
Vous avez des produits, de l'inventaire et un processus d'expédition. Avec trois produits vendus surtout en personne, une page et un lien de paiement vous serviront mieux qu'une boutique.
Ce que ça exige réellement
—Un catalogue et des variantes, avec des fiches produits qui vendent réellement
—Un inventaire qui correspond à la réalité, où qu'elle soit tenue
—Caisse, TPS/TVQ, règles d'expédition, retours et remboursements
—L'exécution des commandes et le service client — les parties qui ne sont pas du logiciel
L'erreur coûteuse
Traiter la boutique comme le projet et les fiches produits comme du remplissage. Le catalogue est le site ; le reste est de la navigation.
Quand acheter bat construire
Pour la majorité des marchands, une plateforme transactionnelle hébergée est la bonne réponse : la caisse, la conformité des paiements et la sécurité deviennent le problème de quelqu'un d'autre. Une caisse sur mesure se justifie quand une règle d'affaires ne peut vraiment pas s'exprimer sur la plateforme — pas parce que la plateforme est démodée.
Site de réservationPermettre de réserver du temps ou de la capacité sans appel téléphonique.＋
Quand c'est suffisant
La disponibilité est précisément ce que les clients veulent savoir, et y répondre à la main vous coûte des heures ou des réservations.
Ce que ça exige réellement
—Des règles de disponibilité et de capacité qui ne peuvent pas être violées
—Confirmations, rappels, annulations et gestion des absences
—Ce que votre personnel utilise déjà pour voir l'horaire de la journée
L'erreur coûteuse
Bâtir un moteur de réservation. Les doubles réservations, les fuseaux, l'heure avancée et les politiques d'annulation sont des problèmes résolus dont les cas limites coûtent cher.
Quand acheter bat construire
Intégrez un logiciel de réservation éprouvé et concevez le site autour. Les restaurants en particulier devraient considérer la plateforme de réservation comme une infrastructure, pas une fonctionnalité : les clients arrivent par elle, et la refaire n'apporte rien qu'un client puisse voir.
Site à abonnementVendre un accès continu, et le retirer quand le paiement s'arrête.＋
Quand c'est suffisant
Il y a réellement du matériel ou une communauté de valeur derrière la barrière, et une raison récurrente de revenir. Sinon, vous avez bâti un mur payant autour d'une bibliothèque que personne ne visite deux fois.
Ce que ça exige réellement
—Comptes, facturation récurrente, changements de forfait et annulations
—Un contrôle d'accès appliqué côté serveur, pas caché dans l'interface
—Un plan de rétention, parce que c'est l'attrition — pas l'inscription — qui décide si ça marche
L'erreur coûteuse
Verrouiller du contenu qui servait mieux à attirer des clients. Certains textes rapportent plus en public que derrière une connexion.
Portail clientDonner à chaque client ses propres informations et son propre suivi, en privé.＋
Quand c'est suffisant
Vos clients vous écrivent aujourd'hui pour connaître un statut, obtenir un document ou revoir un historique, et y répondre coûte du vrai temps de personnel. Le portail se justifie par le volume de ces demandes, pas par son apparence moderne.
Ce que ça exige réellement
—Une isolation stricte des données par client, conçue puis testée
—Authentification, permissions, piste de vérification et récupération de compte
—Une intégration avec l'endroit où vivent réellement les données aujourd'hui
—Un chemin de soutien pour le jour où quelqu'un n'arrive pas à entrer
L'erreur coûteuse
Bâtir le portail avant le processus. Si le processus interne est inconstant, le portail rend cette inconstance visible aux clients.
Outil d'entreprise internePermettre au personnel de travailler plus vite et avec moins d'erreurs.＋
Quand c'est suffisant
Un processus roule sur des chiffriers et de la mémoire, se brise quand la personne qui le connaît est absente, et coûte plus cher en erreurs qu'il ne coûterait à bâtir.
Ce que ça exige réellement
—Un processus écrit et accepté avant qu'on construise quoi que ce soit
—Des rôles, des permissions et une trace de qui a changé quoi
—La vitesse d'utilisation avant le fini visuel — c'est un outil, pas une vitrine
—De la formation, et un responsable après la mise en ligne
L'erreur coûteuse
Refaire un logiciel qu'on pourrait acheter. Le vrai argument pour construire, c'est l'ajustement : quand votre façon de travailler est l'avantage et que les outils génériques vous forcent à travailler comme tout le monde.
Quand acheter bat construire
Si un produit standard couvre quatre-vingts pour cent du processus, achetez-le et ne construisez que la portion qui vous appartient vraiment.
SaaS / application webLivrer le logiciel comme produit lui-même.＋
Quand c'est suffisant
Les gens paient pour ce que le logiciel fait, pas pour ce que votre entreprise fait. À ce moment-là, le site est le marketing d'un produit, et le produit est un projet distinct avec sa propre feuille de route.
Ce que ça exige réellement
—Une portée de produit, un processus de livraison et des environnements autres que la production
—Comptes, facturation, soutien, attentes de disponibilité et posture de sécurité
—Un site marketing capable d'avancer à un rythme différent de l'application
L'erreur coûteuse
Le chiffrer comme un site web. Un questionnaire ne peut pas cadrer une plateforme — les exigences sont la partie coûteuse, et elles n'existent pas encore.
Les combinaisons sont normales et souvent correctes. Une clinique, c'est un site de génération de clients plus une réservation intégrée. Une marque avec des comptes en gros, c'est une boutique plus un portail. Une entreprise de logiciel, c'est un site marketing plus une application. Ce qui compte, c'est de savoir que ce sont deux choses : portées distinctes, cadences de livraison distinctes, budgets généralement distincts — et le site marketing ne devrait jamais attendre après l'application.
Avez-vous vraiment besoin d'un CMS ?
Un système de gestion de contenu est une décision de processus déguisée en logiciel. Répondez à ceci avant de nommer un produit — les réponses éliminent la plupart des options.
Qui modifie — un propriétaire, une personne au marketing, ou plusieurs personnes dans différents services ?
Ce qu'ils modifient — des textes et des images, ou des fiches structurées comme des services, du personnel, des produits ?
À quelle fréquence — quelques fois par année, chaque mois, ou plusieurs fois par semaine ?
Approbations — la personne peut-elle publier directement, ou faut-il une révision ?
Langues — une seule, ou deux qui doivent rester alignées ?
Publication — faut-il planifier, mettre sous embargo ou faire expirer du contenu automatiquement ?
Structure — est-ce des fiches répétitives avec des champs, ou de vraies pages uniques ?
Aucun CMS
Le contenu vit dans le code et les changements sont déployés.
Le contenu change quelques fois par année et une seule personne possède le site. Le plus rapide et le moins cher à exploiter, sans interface d'administration à sécuriser ni à mettre à jour.
Chaque changement de formulation attend un développeur. Acceptable à quatre changements par année, insupportable à quarante.
CMS hébergé
Une plateforme tout-en-un où l'édition, l'hébergement et les gabarits viennent ensemble.
Un propriétaire non technique doit pouvoir tout changer et le design n'a pas à sortir de l'ordinaire. Le moins de friction pour modifier, et la plateforme gère ses mises à jour.
Vous héritez des limites et de la tarification de la plateforme, et les besoins inhabituels deviennent chers rapidement.
CMS découplé (headless)
Le contenu vit dans un système séparé avec une API ; le site s'affiche à partir de là.
Le contenu est structuré et réutilisé — la même fiche de service qui apparaît dans une liste, sur une page détaillée et dans un formulaire — ou plusieurs canaux le consomment, ou plusieurs personnes ont besoin de rôles et d'approbations. C'est aussi la façon la plus propre de tenir deux langues alignées.
Deux systèmes à exploiter, un exercice de modélisation en amont, et une vraie différence entre un bon modèle de contenu et un modèle bâclé.
CMS transactionnel
Une plateforme de commerce où produits, inventaire et commandes sont des objets de premier ordre.
Vendre est le rôle principal. Produits, stock, taxes et caisse sont gérés par un logiciel dont c'est toute la raison d'être, et le marchandisage reste entre les mains du marchand.
Le côté contenu et blogue est généralement plus faible qu'un CMS dédié ; une stratégie de contenu ambitieuse doit être planifiée autour.
Administration sur mesure
Une interface d'édition bâtie spécifiquement pour les fiches de cette entreprise.
Le contenu appartient vraiment à votre domaine — un inventaire avec vos règles, des dossiers clients, des contraintes d'horaire — et un CMS générique forcerait votre personnel à traduire son travail dans le modèle de quelqu'un d'autre.
Vous possédez maintenant une application, avec sa sécurité, ses mises à jour et sa formation. Justifié par un usage quotidien, pas par une préférence.
La bonne réponse est l'option la plus légère qui survit à votre vraie façon de travailler pendant deux ans. La plupart des entreprises achètent trop ici : elles paient un système conçu pour une équipe éditoriale, puis mettent le site à jour deux fois par année en passant par le développeur.
Ce que vous devriez pouvoir changer vous-même
La propriété n'est pas tout ou rien. Certaines choses doivent toujours être à quelques clics du propriétaire ; d'autres doivent rester derrière un processus de développement et de déploiement, parce que les changer à la légère, c'est ainsi qu'un site casse, perd son positionnement ou cesse discrètement de recueillir des demandes.
Quoi
—
Pourquoi
Textes et titres des pages
Vous le changez
Votre offre change plus vite que n'importe quel calendrier de livraison.
Articles de blogue
Vous le changez
Publier ne peut pas dépendre de la disponibilité de quelqu'un d'autre.
Services et descriptions
Vous le changez
Ce que vous vendez vous appartient, et ça évolue.
Équipe, biographies et photos
Vous le changez
Les gens arrivent et partent ; une page d'équipe périmée se lit comme de la négligence.
Produits, prix et inventaire
Vous le changez
Les décisions commerciales ne peuvent pas attendre un déploiement.
Images et galeries
Vous le changez
Un nouveau projet devrait être publiable la semaine où il se termine.
Succursales et heures d'ouverture
Vous le changez
Des heures erronées vous coûtent des clients et nuisent à la recherche locale.
FAQ
Vous le changez
Elles viennent de vraies questions de clients, qui arrivent sans arrêt.
Structure d'URL et redirections
Changé par le développement
Changer des URL à la légère est la façon la plus rapide de perdre un positionnement accumulé.
Gabarits et système de mise en page
Changé par le développement
Une mise en page libre finit par devenir une mise en page incohérente.
Données structurées et métadonnées
Changé par le développement
Elles doivent rester cohérentes sur tout le site pour signifier quelque chose.
Formulaires, livraison et intégrations
Changé par le développement
Un formulaire brisé est invisible ; ça se teste, ça ne se présume pas.
Mesure, consentement et témoins
Changé par le développement
Ça porte des obligations de la Loi 25 et ça brise la mesure quand c'est modifié à l'aveugle.
Accès, permissions et paiements
Changé par le développement
Les changements de sécurité exigent une révision. C'est le seul endroit où la friction est la fonctionnalité.
Le coût de la complexité
Chaque fonctionnalité a un cycle de vie, et la construction en est la partie la moins chère. C'est ce calcul qui détermine si une fonction vaut la peine d'exister — pas sa faisabilité, qui est presque toujours acquise.
Développement
Le seul coût que tout le monde compte, et généralement le plus petit sur cinq ans.
Tests
Chaque fonction multiplie ce qu'il faut revérifier avant chaque mise en ligne.
Sécurité
Connexions, téléversements et paiements ajoutent chacun une surface qu'il faut surveiller.
Hébergement
Bases de données, tâches en arrière-plan et stockage coûtent plus que des pages statiques, chaque mois, pour toujours.
Surveillance
Tout ce qui peut échouer en silence a besoin d'un témoin, sinon c'est un client qui vous l'apprend.
Mises à jour
Les dépendances vieillissent. Un logiciel jamais mis à jour devient un logiciel impossible à mettre à jour.
Formation
Chaque interface d'administration doit être apprise — de nouveau, à chaque changement de personnel.
Entretien
Le contenu dérive, les API changent, les navigateurs avancent. Rien ne reste terminé.
Une fonctionnalité doit exister parce qu'elle crée de la valeur d'affaires, pas parce qu'elle est réalisable. Si personne ne peut nommer le processus qu'elle améliore ou l'argent qu'elle rapporte, ce n'est pas une fonctionnalité : c'est un passif avec une belle interface.
Six entreprises, raisonnées
La même séquence, appliquée à des situations réelles. Aucune ne part d'une plateforme, et deux concluent que la version ambitieuse serait de l'argent gaspillé.
Entrepreneur en construction ou métier spécialisé
L'objectif
Plus de demandes qualifiées de la région, et moins d'appels pour des questions auxquelles le site pourrait répondre.
Ce qui en découle
—Une page par service, écrite comme les clients décrivent le problème
—De la preuve : vraies photos de chantier, vrais avis, territoire desservi clairement nommé
—Un formulaire et un bouton d'appel qui fonctionnent sur un téléphone, dans un camion
—Une présence en recherche locale et des fiches d'entreprise cohérentes
Le type
Un site de génération de clients avec édition de contenu légère. Pas de base de données, pas de comptes, pas de boutique. Le budget appartient aux pages de services et à la preuve, parce que c'est ce qui décide si le téléphone sonne.
Ce que nous ne construirions pas
Pas de connexion client, pas de moteur de soumission, pas de réservation. Une soumission de ce type exige une visite, et un formulaire qui capte les détails du chantier fait le même travail sans l'entretien.
Être le choix crédible évident quand quelqu'un se renseigne sur un problème qu'il n'a jamais eu.
Ce qui en découle
—Du contenu d'autorité qui répond aux questions que les clients posent en premier
—Des pages par domaine de pratique, calquées sur la façon dont les gens cherchent
—Des personnes nommées avec de vrais titres — la confiance, dans ces domaines, est personnelle
—Un chemin de contact qui respecte la confidentialité et pose les attentes
Le type
Un site de contenu et de référencement avec génération de clients, et un CMS avec flux d'approbation — parce que dans une profession réglementée, quelqu'un de senior doit approuver avant publication.
Ce que nous ne construirions pas
Pas de portail client en première phase. C'est un deuxième projet légitime une fois que le volume d'échange de documents le justifie, mais il ne doit jamais retarder le site qui amène les clients.
Remplir les tables et cesser de répondre au téléphone pour les heures et le menu.
Ce qui en découle
—Menu, heures, adresse et stationnement — trouvables en moins de cinq secondes, sur un téléphone
—Des réservations prises de façon fiable au moment où quelqu'un décide de venir
—Des photos qui font ressembler la salle à la salle
—Une fiche Google exacte, que la plupart des gens voient avant le site
Le type
Un site marketing avec une infrastructure de réservation éprouvée intégrée. Les clients arrivent par la plateforme de réservation en laquelle votre personnel de plancher a déjà confiance ; le rôle du site est de les y envoyer sans friction.
Ce que nous ne construirions pas
Ne refaites pas la réservation. Doubles réservations, listes d'attente, dépôts et politiques d'absence sont des problèmes résolus aux cas limites coûteux, et un client ne peut pas savoir qui a écrit le module.
Vendre directement, avec de la marge, sans qu'une personne touche à chaque commande.
Ce qui en découle
—Catalogue avec variantes, tailles et inventaire qui correspond à l'entrepôt
—Caisse, TPS/TVQ selon la province de livraison, règles d'expédition, retours et remboursements
—Des fiches produits qui vendent — photos, coupe, matières, entretien
—Des séquences courriel pour les paniers abandonnés et le rachat
Le type
Un site transactionnel sur une plateforme de commerce hébergée. La caisse, la conformité des paiements et la sécurité cessent d'être votre problème, et le budget se déplace vers les fiches produits et la marque — là où se joue vraiment la différence de conversion.
Ce que nous ne construirions pas
Pas de caisse sur mesure, et pas de système d'inventaire maison avant qu'il y ait de l'inventaire. À revoir seulement quand une règle d'affaires précise ne peut vraiment pas s'exprimer sur la plateforme.
Attirer des demandes qualifiées et cesser de perdre des heures en suivi et en administration.
Ce qui en découle
—Du contenu par destination et par spécialité qui gagne du trafic de recherche
—Un parcours de demande qui qualifie avant de réserver du temps à l'agenda
—Un CRM qui détient la relation client, pas une boîte courriel
—Éventuellement, un espace où le client voit son itinéraire et ses documents
Le type
Un site hybride, bâti dans cet ordre : contenu et génération de clients d'abord, puis un espace client quand le volume de courriels de suivi le prouve. Le site public amène les clients ; le portail réduit le coût de les servir.
Ce que nous ne construirions pas
Pas les deux en même temps. Un portail bâti avant d'avoir assez de clients pour le remplir, c'est de l'entretien sans retour, et ça retarde la partie qui génère des revenus.
Gagner des mandats publiquement tout en remplaçant les chiffriers sur lesquels l'entreprise roule réellement.
Ce qui en découle
—Un site public crédible qui vend la capacité
—Un outil interne qui correspond au vrai processus, écrit d'abord
—Des rôles, des permissions et une piste de vérification
—Une intégration avec la comptabilité ou l'horaire déjà en place
Le type
Deux produits : un site public et un logiciel interne sur mesure. Ils partagent une marque et presque rien d'autre — utilisateurs différents, mesures de succès différentes, cadences différentes.
Ce que nous ne construirions pas
Ne mettez pas les outils du personnel derrière une connexion sur le site marketing pour économiser. Ça complique le site public, ça contraint l'outil, et ça donne aux deux une posture de sécurité plus faible que si chacun vivait seul.
Écrivez une réponse à chacun de ces points avant de parler à qui que ce soit de construction. Ça prend un après-midi, ça rend les soumissions comparables, et c'est la différence entre acheter un site et en commander un.
Objectif et action
Le résultat commercial, en une phrase, chiffré si possible
La seule action qu'un visiteur doit poser pour que ce résultat arrive
Comment vous saurez que ça a fonctionné, et qui regarde ça
Fonctions et contenu
Les pages qui doivent exister au lancement, et qui les écrit
Les types de contenu répétitifs — services, équipe, produits, succursales, FAQ
La fréquence de changement de chacun, et qui le change
Les langues, et qui garde la deuxième à jour
Systèmes et administration
Chaque système avec lequel le site doit échanger des données, et s'il a une API
Où va une demande ou une commande après l'envoi
Qui modifie, qui approuve, qui a un compte, et ce que chacun ne doit jamais pouvoir briser
Données, croissance et entretien
Quelles données personnelles ou de paiement sont recueillies, et où elles résident (Loi 25)
À quoi ressemble une croissance réaliste sur douze mois
Qui l'entretient, avec quel budget, et qui on appelle quand ça casse
Ce que vous choisissez délibérément de ne pas construire en phase un
La dernière ligne est celle qui économise le plus. Une liste écrite de ce qui est hors portée vaut plus qu'une longue liste de ce qui est inclus.
Questions
Quel type de site web mon entreprise a-t-elle besoin ?
La majorité des entreprises ont besoin d'un site de génération de clients : des pages qui expliquent l'offre, des formulaires qui se rendent réellement à une personne, et une mesure qui montre quelles pages produisent des demandes. Un site transactionnel s'impose quand vous vendez des produits directement, un site de réservation quand les clients réservent du temps, des comptes quand quelque chose de réellement privé se trouve derrière une connexion, un portail quand chaque client a besoin de son propre dossier, et une application quand le logiciel est le produit. Tout ce qui dépasse ce que le processus d'affaires exige ajoute un coût permanent sans ajouter de revenu.
Site vitrine ou site transactionnel : comment choisir ?
La question est de savoir si la vente se conclut sur le site. Si le client achète en ligne, il vous faut un site transactionnel : catalogue, inventaire, caisse, TPS/TVQ, expédition et retours. Si la vente se conclut dans une conversation, un site vitrine bien construit — avec des pages de services et des formulaires qui convertissent — fait le travail pour une fraction du coût d'exploitation. Une boutique sans produits à vendre est un coût d'entretien permanent sans revenu.
Ai-je vraiment besoin d'un CMS ?
Seulement si une personne non technique doit modifier du contenu sans développeur, ou si le contenu change plus de quelques fois par année. Si une seule personne possède le site et qu'il change rarement, aucun CMS est l'option la plus rapide et la moins chère. Si le contenu est structuré et répétitif — services, équipe, produits, succursales — un CMS structuré ou découplé se justifie. Des approbations ou deux langues à tenir alignées éliminent les options les plus simples et constituent une vraie raison d'accepter un système plus lourd.
Mon site doit-il obligatoirement être en français au Québec ?
Oui pour le contenu commercial destiné au public québécois : la Charte de la langue française, modifiée par la Loi 96, exige que l'information commerciale soit disponible en français dans une version au moins équivalente à celle offerte dans une autre langue. Concrètement, ça veut dire que le français n'est pas une traduction ajoutée après coup — c'est une exigence de contenu qui double l'opération éditoriale et qui doit être planifiée avant le choix du CMS, pas après.
Faut-il choisir la plateforme avant de définir les besoins ?
Non. Choisir WordPress, Shopify, Framer, Next.js ou Supabase avant que les exigences existent inverse la décision : on s'engage d'abord dans des contraintes, puis on découvre ce dont l'entreprise avait besoin. Descendez la séquence — objectif d'affaires, action du visiteur, fonctions, contenu, intégrations, administration, sécurité, croissance — et seulement ensuite la technologie. Si deux plateformes répondent également à tout ça, le choix entre elles n'est pas la décision importante.
Quand faut-il construire plutôt qu'acheter ?
Construisez quand votre façon de travailler est l'avantage et qu'un logiciel générique vous forcerait à travailler comme tout le monde. Achetez quand le problème est déjà résolu et que ses cas limites coûtent cher : paiements, réservation, livraison de courriels et caisse transactionnelle en sont les exemples habituels. Si un produit standard couvre environ quatre-vingts pour cent du processus, achetez-le et ne construisez que la portion qui vous appartient vraiment.
La suite
Vous avez des exigences. Voici les prochaines décisions, à peu près dans l'ordre où elles comptent.