CMS et développement sur mesure : quand en avez-vous besoin ?

Pour un site d’entreprise, commencez par vérifier ce qu’un CMS existant peut gérer après configuration. Ajoutez du développement sur mesure pour les fonctions que vos besoins justifient : une intégration, un parcours éditorial ou une règle métier. Créer votre propre CMS demande un motif plus solide, car vous devrez aussi maintenir les fonctions d’administration et de publication.

La décision concerne autant les personnes qui publient que la technologie. Faites tester les tâches réelles à vos rédacteurs avant de choisir : créer une page, préparer sa traduction, faire valider une modification et retrouver une ancienne version.

Trois niveaux de personnalisation à distinguer

Un site conçu pour votre entreprise peut utiliser un CMS existant. « Sur mesure » peut décrire son design, ses modèles de contenu ou certaines fonctions, sans signifier que l’équipe développe tout le système.

Configurer un CMS

Travail à réaliser — Définir les contenus, modèles, langues et droits avec les mécanismes disponibles

Point à vérifier — Les éditeurs peuvent-ils accomplir leurs tâches sans contournement ?

Étendre un CMS

Travail à réaliser — Ajouter une fonction, un connecteur ou une interface spécifique

Point à vérifier — Qui maintient le code et teste sa compatibilité lors des mises à jour ?

Développer un système dédié

Travail à réaliser — Concevoir l’administration et les fonctions de publication nécessaires

Point à vérifier — Quel besoin justifie de prendre en charge ce périmètre supplémentaire ?

La configuration peut elle-même nécessiter un développeur. Elle peut passer par des fichiers, des modèles ou des extensions ; elle ne signifie pas forcément « aucun code ». Demandez au prestataire de distinguer les fonctions standard, les modules tiers et le code spécifique dans sa proposition.

Décrire vos besoins avant de comparer les outils

Recensez les contenus à publier : pages de services, articles, références, documents ou fiches produits. Pour chaque type, définissez les champs, les relations et les personnes autorisées à le modifier. Indiquez les langues et la personne qui valide chaque version.

Écrivez ensuite des scénarios observables. « Un rédacteur prépare une modification française ; un responsable la valide ; la version publiée reste visible pendant la relecture » permet de tester une solution. « Un CMS flexible et intuitif » laisse trop de place à l’interprétation.

Classez vos exigences en trois groupes : indispensables au lancement, utiles ensuite et facultatives. Pour chaque fonction spécifique, notez le problème actuel, les personnes concernées et ce qu’elles feraient sans elle. Vous pourrez écarter un développement dont l’utilité ne justifie pas la maintenance.

Ce que montrent Sulu, Drupal et WordPress

Les trois outils permettent de construire des sites adaptés à des besoins précis. Leurs mécanismes et leur mise en œuvre diffèrent ; vérifiez la version et les extensions retenues dans votre projet.

La documentation Sulu 3.x décrit des espaces de site, des pages organisées en arborescence, des langues et des modèles qui définissent les propriétés des pages. Vous pouvez donc prévoir des structures de contenu propres à votre site en vous appuyant sur cette architecture.

Dans Drupal, le module Content Moderation permet de conserver une version publiée pendant la préparation d’une version à relire. Son association avec Content Translation permet de modérer chaque traduction séparément. Vous devez configurer les états, transitions et permissions adaptés à votre organisation.

Content Moderation et Workflows sont des modules du cœur de Drupal. La création automatique du parcours « Editorial » dépend du profil d’installation ; faites vérifier sa configuration. La modération séparée ne signifie pas que toute modification du français déclenche automatiquement la mise à jour de l’anglais.

WordPress permet d’enregistrer des types de contenu spécifiques. Sa documentation recommande de placer leur définition dans un plugin plutôt que dans le thème pour préserver cette organisation des contenus lors d’un changement de thème.

Ces exemples décrivent des possibilités, pas un classement. Une fonction disponible dans la documentation ne prouve pas que le projet livré l’inclut ou que votre équipe saura l’utiliser. Demandez une démonstration dans le périmètre proposé.

Choisir à partir des besoins qui restent sans réponse

Utilisez cet ordre de décision :

1. Testez le besoin avec les fonctions du CMS retenu et sa configuration.

2. Si le test échoue, examinez une extension maintenue et compatible, ou simplifiez le besoin si cela reste acceptable.

3. Si une fonction manque encore, définissez une extension spécifique avec son contrat de maintenance et ses tests.

4. Envisagez un système dédié si les contraintes centrales ne peuvent pas être satisfaites de manière raisonnable par les solutions évaluées. Documentez les alternatives écartées et le coût des fonctions que vous devrez reconstruire.

Une équipe peut aussi garder le CMS pour les contenus publics et confier les opérations métier à un outil distinct. Un espace client transactionnel ou un CRM ne doit pas nécessairement partager le même système de publication que le site institutionnel.

Exemple de cadrage pour un site FR/EN

Cet exemple est un scénario de réception proposé, pas un cas client ni une promesse de résultat.

Publication bilingue

Test à demander — Modifier le français sans publier ni écraser l’anglais

Développement à envisager si nécessaire — Connecteur de traduction ou suivi spécifique des versions

Validation

Test à demander — Un rédacteur enregistre un brouillon sans pouvoir publier

Développement à envisager si nécessaire — Extension du parcours de validation

Informations venant d’un outil métier

Test à demander — Importer une donnée, puis simuler une indisponibilité de la source

Développement à envisager si nécessaire — Connecteur avec journal d’erreurs et reprise maîtrisée

Changement d’URL

Test à demander — Vérifier l’ancienne et la nouvelle adresse après migration

Développement à envisager si nécessaire — Gestion des redirections dans le CMS ou la couche serveur

Départ d’un prestataire

Test à demander — Exporter les contenus et documenter leur structure

Développement à envisager si nécessaire — Export supplémentaire pour les champs spécifiques

Pour une intégration, désignez le système qui fait référence pour chaque donnée. Précisez le sens des échanges, les règles de modification et le comportement en cas d’échec. La présence d’une API ne règle pas à elle seule ces décisions.

Headless : évaluer aussi le travail éditorial

Dans une architecture headless, l’équipe sépare la gestion du contenu de l’interface qui le présente aux visiteurs. Elle peut servir plusieurs interfaces depuis une même source. Examinez cette option si vous avez un besoin réel de diffusion ou des contraintes de présentation qui la justifient.

Comparez aussi le travail supplémentaire : prévisualisation des brouillons, rendu des pages, URLs, langues, recherche et déploiement. Demandez qui prend en charge chaque fonction. Évaluez la vitesse sur des pages et des contenus représentatifs ; l’étiquette « headless » ne garantit ni rapidité ni meilleur référencement.

Pour un site corporate que votre équipe doit mettre à jour sans aide technique, testez la prévisualisation et la publication avec autant d’attention que la partie visible. Un site que les visiteurs apprécient peut être difficile à maintenir pour les rédacteurs.

Calculer le coût d’exploitation sur un même périmètre

Comparez les propositions sur une durée commune, par exemple trois ans. Ce choix sert au calcul, pas de durée standard imposée. Utilisez : coût initial + coûts récurrents sur la période + évolutions prévues + coût de sortie estimé. Séparez les montants certains des hypothèses et précisez la TVA.

Le coût initial comprend le cadrage, le design, la configuration, le code spécifique, les intégrations et la migration. Ajoutez les contenus, traductions, tests et formation lorsqu’ils ne figurent pas dans le devis. Pour le détail du périmètre d’un site, consultez notre guide sur le budget d’un site web en Suisse.

Les coûts récurrents couvrent selon le projet l’hébergement, les licences, les mises à jour, le suivi technique et le support. Demandez aussi le coût des tests de non-régression après une mise à jour et la prise en charge des extensions abandonnées. Une solution sans licence payante peut nécessiter du travail d’exploitation.

Consignez les exclusions : production de contenu, assistance aux éditeurs, corrections de données importées ou nouvelles fonctions. Demandez ce que couvre la garantie et ce qui relève du contrat de maintenance. Une proposition moins chère peut porter sur un périmètre plus réduit.

Prévoir la maintenance et la reprise du projet

Identifiez le responsable des mises à jour du CMS, des extensions et du code spécifique. Vérifiez comment l’équipe suit les dépendances, teste les droits et restaure une sauvegarde. Le nombre de plugins seul ne vous permet pas d’évaluer la sécurité d’un site.

Prévoyez un environnement de test et une procédure de publication. Pour les intégrations, demandez un journal d’erreurs accessible aux personnes qui devront intervenir. Définissez le traitement d’une importation partielle et la façon de réessayer sans créer de doublons.

À la livraison, récupérez les accès qui vous reviennent, les fichiers et la documentation prévus au contrat. Faites préciser les droits sur le code, les licences tierces, les limites des exports et les conditions de transfert à un autre prestataire. Un export réussi doit permettre de comprendre les relations entre contenus, médias et traductions.

Les tests à réaliser avant d’accepter la livraison

Demandez à un rédacteur et à un responsable de réaliser les tâches prévues avec leurs propres droits. Testez les brouillons, la prévisualisation, les validations, les médias et les deux langues. Vérifiez également une restauration et un export représentatif.

Pour la migration, contrôlez les anciennes URLs, les redirections, les liens internes et les annotations de langue. Conservez des critères de réception pour les parcours importants et le rendu sur mobile. Notre prestation de création et refonte de sites web permet de cadrer ces besoins avec le contenu et les interfaces.

Testez aussi la reprise des champs, médias et relations entre traductions sur un échantillon représentatif. Précisez au contrat les éléments remis pour une reprise : contenus exportés, code et configuration auxquels vous avez droit, documentation du modèle et procédure de déploiement. Un fichier de textes seul peut laisser de côté ce dont le prochain prestataire aura besoin.

Le critère de choix est le fonctionnement démontré sur vos scénarios, avec une équipe et un budget capables de l’entretenir. Gardez les exigences, les résultats des tests et les responsabilités dans un document commun.

Questions fréquentes

Un CMS existant limite-t-il le design ?

Le résultat dépend des modèles, du thème et de l’architecture retenus. Demandez une démonstration des composants importants et de leurs règles d’édition. Distinguez les contraintes utiles à la cohérence des pages des limites qui empêchent vos usages.

Faut-il développer son CMS pour garder la maîtrise du site ?

La maîtrise dépend aussi des accès, de la documentation, des droits contractuels et de la capacité d’un autre prestataire à reprendre le projet. Examinez ces points pour toutes les options, y compris un développement dédié.

Peut-on ajouter les intégrations après le lancement ?

Oui, si l’architecture et les systèmes concernés le permettent. Définissez les données et les interfaces importantes dès le cadrage, même si vous reportez la réalisation. Vous éviterez de considérer comme acquise une intégration qui nécessite des changements de structure.

Comment choisir entre Sulu, Drupal et WordPress ?

Évaluez les scénarios éditoriaux, les langues, les intégrations, les compétences disponibles et le coût d’exploitation. Demandez à l’équipe proposée de montrer comment elle réalise vos tâches sur la version et les extensions qu’elle compte livrer.