Rails MVC : routes, contrôleurs et vues en pratique

Votre application AtelierFix tourne, mais elle affiche encore la page d’accueil générique de Rails. À la première personne à qui vous la montrez, vous voudrez votre propre écran — par exemple un tableau de bord « Atelier de Modou » avec la date du jour. Pour y arriver, il faut comprendre le trajet qu’une requête parcourt entre l’URL tapée par le navigateur et le HTML renvoyé. Ce trajet porte un nom : MVC. C’est le concept central de Rails ; une fois qu’il est clair, tout le framework devient lisible.

Dans ce tutoriel, on remplace la page par défaut par un vrai tableau de bord servi par notre propre route, notre contrôleur et notre vue. Rien de magique : juste les trois pièces du puzzle, posées dans le bon ordre.

🎯 Ce que vous allez apprendre

• Décrire le cycle d’une requête dans Rails : route → contrôleur → vue ;
• Générer un contrôleur et lui rattacher une action ;
• Déclarer une route et en faire la page d’accueil du site ;
• Écrire une vue ERB et y injecter une donnée calculée côté serveur ;
• Lire un message d’erreur de routage et le corriger seul.

🛠️ Ce que vous allez construire

Le tableau de bord d’AtelierFix : une page d’accueil sur mesure qui affiche un titre, un mot de bienvenue et la date du jour calculée par le serveur. C’est modeste, mais c’est la première brique visible de l’application — et elle vous fait manipuler les trois couches de Rails en même temps.

Prérequis

• Avoir terminé le tutoriel Installer Ruby et Rails : l’application atelierfix doit exister et démarrer avec bin/rails server.
• Un éditeur de code (VS Code fait très bien l’affaire).
• ⏱️ Temps estimé : ~35 minutes.

MVC : le modèle mental à avoir en tête

MVC découpe l’application en trois responsabilités. Le Modèle (Model) gère les données et les règles métier — il dialogue avec la base. La Vue (View) produit ce que l’utilisateur voit, en général du HTML. Le Contrôleur (Controller) fait le chef d’orchestre : il reçoit la requête, demande au modèle ce dont il a besoin, puis choisit la vue à rendre.

À ces trois pièces, Rails ajoute le routeur, le portier d’entrée. Quand le navigateur demande http://localhost:3000/, voici ce qui se passe : le routeur lit l’URL, la fait correspondre à une action de contrôleur, le contrôleur s’exécute et prépare des données, puis rend la vue associée, qui renvoie le HTML au navigateur. Tout l’enjeu de ce tutoriel tient dans cette phrase — on va la rendre concrète, pièce par pièce.

Étape 1 — Générer un contrôleur

On commence par le contrôleur, car c’est lui qui orchestre la page. Rails sait en fabriquer un avec une action prête à l’emploi. Depuis le dossier atelierfix :

bin/rails generate controller Dashboard index

Cette commande crée plusieurs fichiers d’un coup. Les deux qui nous intéressent : app/controllers/dashboard_controller.rb (le contrôleur, avec une méthode index vide) et app/views/dashboard/index.html.erb (la vue qui lui correspond). Rails a aussi ajouté une route get "dashboard/index" dans config/routes.rb — pratique, mais on va la remplacer par quelque chose de plus propre à l’étape suivante. Notez la convention : un contrôleur Dashboard cherche ses vues dans le dossier dashboard/, et l’action index rend le fichier index.html.erb. Ce nommage n’est pas un hasard, c’est la « convention » de Rails qui vous évite d’écrire de la configuration.

Étape 2 — Déclarer la route d’accueil

On veut que la racine du site — http://localhost:3000/ — mène à notre tableau de bord, et non à la page Rails par défaut. Le routeur se configure dans config/routes.rb. Ouvrez ce fichier et remplacez la ligne get "dashboard/index" par une déclaration root :

Rails.application.routes.draw do
  root "dashboard#index"
end

La syntaxe "dashboard#index" se lit « contrôleur dashboard, action index ». Le root est la route spéciale qui répond à l’URL racine. Sauvegardez, puis rechargez http://localhost:3000 : la page Rails par défaut a disparu, remplacée par une page presque vide. C’est bon signe — le routeur trouve désormais notre contrôleur.

✅ Point d’étape — À ce stade, la racine du site mène à votre action index. Si vous voyez une erreur uninitialized constant DashboardController, c’est que le contrôleur n’a pas été généré ou que le serveur n’a pas rechargé : arrêtez-le (Ctrl + C) et relancez bin/rails server.

Étape 3 — Écrire la vue

La vue est le fichier que le contrôleur rend. Pour l’instant elle contient le texte généré automatiquement. Ouvrez app/views/dashboard/index.html.erb et remplacez tout par votre propre HTML :

<h1>Atelier de Modou</h1>
<p>Bienvenue sur AtelierFix, le suivi des réparations de l'atelier.</p>

L’extension .html.erb signifie « HTML embarquant du Ruby » (Embedded Ruby). Tant qu’on n’y met que du HTML, c’est une page statique ordinaire. Rechargez le navigateur : votre titre et votre phrase s’affichent. Vous venez de servir votre première page sur mesure — route, contrôleur et vue collaborent.

Étape 4 — Injecter une donnée dynamique

Une page figée n’a pas grand intérêt. Tout le sel du serveur, c’est de calculer quelque chose puis de l’afficher. On va passer la date du jour du contrôleur à la vue. Dans app/controllers/dashboard_controller.rb, renseignez l’action index :

class DashboardController < ApplicationController
  def index
    @aujourdhui = Date.current
  end
end

La variable @aujourdhui commence par une arobase : c’est une variable d’instance, et Rails a la bonne idée de rendre ces variables-là visibles dans la vue. Date.current renvoie la date du jour selon le fuseau de l’application. Maintenant, affichez-la dans la vue avec une balise ERB :

<h1>Atelier de Modou</h1>
<p>Bienvenue sur AtelierFix, le suivi des réparations de l'atelier.</p>
<p>Nous sommes le <%= @aujourdhui.strftime("%d/%m/%Y") %>.</p>

La balise <%= … %> évalue du Ruby et insère le résultat dans la page (le signe égal compte : <% … %> sans égal exécute du Ruby sans rien afficher). strftime formate la date à la française. Rechargez : la date du jour apparaît, calculée par le serveur à chaque visite.

✅ Point d’étape — Votre page affiche une donnée produite par le contrôleur. Vous tenez le cycle MVC complet : le routeur a appelé l’action, l’action a préparé @aujourdhui, la vue l’a affichée. Si la page montre %= @aujourdhui % en texte brut, c’est que vous avez oublié le < ouvrant de la balise ERB.

Voir toutes les routes d’un coup d’œil

À mesure que l’application grandit, on perd vite le fil des URLs qu’elle reconnaît. Rails fournit une commande qui liste l’intégralité des routes actives :

bin/rails routes

La sortie affiche, pour chaque route, le verbe HTTP (GET, POST…), le motif d’URL, et le couple contrôleur#action visé. Pour l’instant vous n’y verrez qu’une ligne — votre root — mais gardez cette commande en tête : dès le tutoriel sur le CRUD, une seule ligne resources :reparations en générera sept d’un coup, et bin/rails routes deviendra votre meilleur allié pour comprendre ce que Rails a câblé pour vous. Vous pouvez filtrer avec bin/rails routes -g dashboard pour ne voir que les routes contenant « dashboard ».

La convention qui relie tout sans configuration

Vous avez peut-être remarqué qu’on n’a jamais dit à Rails que l’action index devait rendre index.html.erb, ni que le contrôleur Dashboard lisait ses vues dans app/views/dashboard/. Rails l’a déduit. C’est le principe qui le caractérise : la convention plutôt que la configuration. Tant que vous respectez le nommage attendu, le framework câble les pièces tout seul ; vous n’écrivez de la configuration que pour les cas inhabituels.

Concrètement, la règle se lit comme une chaîne de noms cohérents :

• le contrôleur DashboardController vit dans app/controllers/dashboard_controller.rb (nom en snake_case, suffixe _controller) ;
• ses vues sont rangées dans app/views/dashboard/ (le nom du contrôleur, au pluriel naturel du dossier) ;
• l’action index rend, sauf indication contraire, le fichier index.html.erb ;
• un futur modèle Reparation correspondra à la table reparations en base.

Cette régularité a un double effet. D’abord, elle vous fait écrire beaucoup moins de code : pas de fichier de mapping à tenir à jour. Ensuite, elle rend les projets Rails interchangeables — un développeur qui ouvre votre dépôt sait d’avance où chaque chose se trouve. L’inconvénient ? Quand on débute, une faute de frappe dans un nom de fichier casse la magie sans message évident. Le réflexe à prendre : devant un Template is missing ou un uninitialized constant, vérifiez d’abord l’orthographe et l’emplacement exact, pas votre logique.

🐞 Pièges fréquents

🌍 Adaptation au contexte ouest-africain

La date affichée dépend du fuseau horaire de l’application. Par défaut Rails travaille en UTC, ce qui décale l’affichage d’une heure par rapport à Dakar ou Abidjan (qui sont à GMT). Pour un atelier qui n’opère que localement, fixez le fuseau dans config/application.rb avec config.time_zone = "Africa/Dakar" ; les dates et heures s’aligneront alors sur l’horloge de l’atelier. C’est un réflexe à prendre tôt : un rendez-vous de réparation affiché avec une heure de décalage, c’est un client qui se déplace pour rien.

✅ Récapitulatif

Vous avez transformé la page d’accueil générique en un tableau de bord à vous, et surtout vous avez vu le cycle MVC en action : le routeur dirige la requête vers une action de contrôleur, l’action prépare des données dans des variables d’instance, et la vue ERB les met en page. C’est le mécanisme que vous répéterez dans chaque écran de Rails — il ne changera plus, seules les données deviendront plus riches.

🧾 Aide-mémoire

💪 À vous de jouer

Ajoutez une seconde donnée dynamique : un compteur fictif de réparations en cours, par exemple « 4 réparations en attente ». Préparez la variable dans le contrôleur et affichez-la dans la vue.

# app/controllers/dashboard_controller.rb
def index
  @aujourdhui = Date.current
  @en_attente = 4
end

<!-- app/views/dashboard/index.html.erb -->
<p><%= @en_attente %> réparations en attente.</p>

Tutoriels frères

• Installer Ruby et Rails : l’environnement de A à Z — le prérequis si AtelierFix n’existe pas encore.
• Active Record : modèles, migrations et associations — remplacer les données figées par une vraie base.

Pour aller plus loin

• 🔝 Retour au guide principal : Ruby on Rails : le guide complet pour débuter
• Documentation officielle : Rails Routing from the Outside In et Action View Overview

FAQ

Quelle différence entre <%= %> et <% %> ?
Avec le signe égal, Rails affiche le résultat dans la page (idéal pour une valeur). Sans le signe égal, le Ruby s’exécute mais n’affiche rien — c’est ce qu’on utilise pour une boucle ou une condition qui entoure du HTML.

Pourquoi mes variables doivent-elles commencer par @ ?
Seules les variables d’instance (préfixées par @) sont partagées entre le contrôleur et sa vue. Une variable locale ordinaire (x = 4) resterait invisible dans la vue.

Dois-je créer une route pour chaque page ?
Pour des pages isolées comme un tableau de bord, oui. Mais pour gérer une ressource complète (créer, lire, modifier, supprimer des réparations), une seule ligne resources génère toutes les routes nécessaires — c’est l’objet du tutoriel sur le CRUD.

Où placer la logique compliquée ?
Pas dans la vue. La vue affiche ; le contrôleur coordonne ; les calculs et les règles métier descendent dans le modèle. Garder ce partage net — vue qui affiche, contrôleur qui coordonne, modèle qui décide — c’est exactement ce qui maintient une application Rails lisible quand elle grossit, et ce qui vous évitera de tout réécrire dans six mois.