Du nom au sens : conventions, cohérence et langage du code

Nommer, pour nous, c’est bien plus qu’associer un mot à une fonction ou une variable. C’est déjà structurer une pensée, poser un cadre, traduire une intention. Derrière chaque table, chaque champ, chaque fichier, il y a un choix collectif : celui d’une logique de lecture, d’une cohérence visuelle et d’une hiérarchie de sens. Au fil de nos projets chez Pem’s Projects, cette grammaire s’est affinée, non pour imposer des règles, mais pour nous permettre de relier les langages,  SQL, PHP, JSON, JavaScript, HTML, dans une même continuité.

Au travers de cet article, nous explorons ces conventions à travers notre pratique : comment la façons d’écrire un identifiant, de structurer un nom, d’utiliser une casse ou un séparateur, exprime une vision du code et du monde qu’il modélise. De la table tab_options aux attributs data-*, du video_training au videoTraining, chaque forme raconte notre manière de penser la relation entre les données, les objets et les usages.

Notre objectif n’est pas de définir un standard, mais de partager une vision, de montrer comment des conventions simples peuvent devenir un langage commun. Un langage où la forme, la syntaxe et le sens avancent ensemble pour rendre le code lisible, transmissible et vivant.

Nommer pour penser : donner forme et sens au code

Nommer, c’est bien plus qu’une question de technique ou d’habitude. C’est un geste de conception, concret et sensible, où la main écrit ce que l’esprit cherche à ordonner. Chez Puce & Média, nous voyons dans le nommage une forme de pensée incarnée : nommer, c’est déjà comprendre ce que l’on fait exister, donner corps à une idée à travers une forme lisible.

Un tab_users bien choisi parle de sa fonction, là où un usersTable hésite entre l’objet et le décor. Un ch_user_id raconte une filiation logique, là où un simple id perd son contexte. Chaque mot, chaque casse, chaque liaison exprime une intention. Un nom juste évite l’explication inutile, il se lit comme une évidence, une respiration du code.

-- Dans le code qui suit, cette cohérence se lit immédiatement :
-- Conventions cohérentes
SELECT ch_user_id, ch_user_name
FROM tab_users;

-- Variante ambiguë
SELECT id, name
FROM usersTable;

-- Dans le code qui suit, cette cohérence se lit immédiatement :
-- Conventions cohérentes
SELECT ch_user_id, ch_user_name
FROM tab_users;

-- Variante ambiguë
SELECT id, name
FROM usersTable;

Penser le nommage, c’est donc penser la matière du projet : celle qui relie la base à l’interface, la donnée à l’action, le concepteur à celui qui relira. La rigueur de forme n’est pas une contrainte mais un accord, un rythme commun entre nous, les langages et la machine. Nommer, c’est déjà relier, et relier, c’est déjà comprendre.

Bases de données : le socle

Nos conventions de nommage prennent racine dans la structure même des bases de données. Tout part du choix de désigner les tables avec un préfixe explicite : tab_ : qui indique immédiatement la nature de l’objet manipulé. Ainsi, tab_clubs ou tab_users décrivent des ensembles, des collections de données. Le pluriel est logique : une table contient plusieurs éléments d’un même type.

Les champs, eux, portent le préfixe ch_, abréviation de champ, suivi du nom de la table d’origine et d’un identifiant singulier. Cette syntaxe rend chaque champ immédiatement reconnaissable : ch_club_id, ch_club_etat, ch_user_id, ch_user_etat. Pour des tables au nom plus long, comme tab_mouvements, nous simplifions par une contraction du nom : ch_mvt_id, ch_mvt_type, assurant à la fois clarté et homogénéité. Le nom devient autoporteur, éliminant toute ambiguïté sur son contexte.

Cette rigueur s’étend naturellement aux clés étrangères, marquées par le préfixe fk_, ou aux index s’appuyant sur idx_, garantissant une lecture fluide dans les jointures et les schémas d’exécution. Mais cette logique peut aller plus loin. Les triggers utilisent souvent le préfixe trg_, les contraintes de validation le préfixe chk_, les vues celui de vw_, les procédures stockées sp_, les fonctions stockées fn_, les séquences seq_ et les tables temporaires tmp_.

Chaque préfixe agit comme un repère visuel et mental : en un instant, il indique la nature, la portée et le comportement de l’objet SQL concerné. L’usage systématique de l’underscore (_) renforce cette cohérence visuelle, en séparant clairement les éléments du nom et en assurant une compatibilité maximale et la maintenabilité, notamment lors des échanges entre systèmes ou langages externes.

Dans nos requêtes, nous avons choisi de nommer les alias en uppercase : USERS, CLUBS, PROFILES. Cela permet de distinguer immédiatement les entités logiques des mots-clés SQL (SELECT, FROM, JOIN, WHERE, ORDER). La requête gagne en relief et en rythme de lecture.

SELECT 
    USERS.ch_user_id AS USER_ID,
    USERS.ch_user_name AS USER_NAME,
    CLUBS.ch_club_label AS USER_CLUB_LABEL
FROM tab_users AS USERS
LEFT JOIN tab_clubs AS CLUBS ON CLUBS.ch_club_id = USERS.fk_user_club_id
WHERE USERS.ch_user_etat = '1'
ORDER BY USER_NAME ASC;

SELECT 
    USERS.ch_user_id AS USER_ID,
    USERS.ch_user_name AS USER_NAME,
    CLUBS.ch_club_label AS USER_CLUB_LABEL
FROM tab_users AS USERS
LEFT JOIN tab_clubs AS CLUBS ON CLUBS.ch_club_id = USERS.fk_user_club_id
WHERE USERS.ch_user_etat = '1'
ORDER BY USER_NAME ASC;

Dans cet extrait, tout est lisible à la première lecture : on identifie la table principale, les champs, les relations et les alias sans effort. Chaque élément joue un rôle précis : les tables structurent, les champs décrivent, les clés relient, les alias clarifient. Le code devient un langage où la forme révèle la fonction. Cette cohérence visuelle et logique constitue le socle de notre manière d’écrire le code, et donc de penser la donnée.

Langages serveur et client : écrire avec les mêmes repères

Passer des tables SQL aux langages serveur et client, c’est prolonger le même fil : celui du sens. Une base bien nommée ne sert à rien si les scripts qui l’exploitent brisent la logique qu’elle propose. Chez Puce & Média, nous veillons à ce que la cohérence du nommage se poursuive de bout en bout : du schéma SQL au code PHP, jusqu’aux interfaces en JavaScript ou Vue.js.

Ainsi, un champ ch_user_name côté base devient naturellement $user_name en PHP, user_name dans un JSON, puis data-username dans un attribut HTML. Chaque translation conserve la racine, le rythme et la lisibilité. Cette continuité rend le code prévisible et les échanges entre couches beaucoup plus fluides.

Les formes d’écriture varient selon les contextes, mais leur logique reste la même. L’underscore (_) s’impose pour les variables serveur et les données : clair, stable et compatible avec la majorité des langages. Le camelCase (videoTraining) appartient davantage aux objets et fonctions JavaScript, où la casse devient un repère visuel. Le kebab-case et/ou snake-case (video-training) s’exprime côté HTML ou CSS, où il favorise la lisibilité des identifiants et des classes.

// Un même concept décliné selon les contextes
let videoTraining = {
    title: "Analyse visuelle d'entrainement",
    url: "video_training_view.php",
    dataset: { tag_id: 42 }
};

// Un même concept décliné selon les contextes
let videoTraining = {
    title: "Analyse visuelle d'entrainement",
    url: "video_training_view.php",
    dataset: { tag_id: 42 }
};

Chaque style d’écriture sert un rôle, et c’est leur alignement qui fait la force du système. Ce n’est pas une simple convention graphique, mais une manière d’assurer une compréhension transversale : chaque fichier, chaque ligne, parle la même langue, avec son accent propre mais une syntaxe commune.

Une syntaxe qui relie tout

Au-delà des langages eux-mêmes, la cohérence s’étend à tout ce qui structure un projet : l’arborescence des dossiers, le nom des fichiers, les scripts et les points d’entrée. Ce que nous avons vu avec video_training_view.php illustre bien cette continuité : le nom du fichier, comme celui des fonctions et des variables qu’il contient, porte déjà le sens du rôle qu’il joue dans le système.

Cette rigueur de syntaxe simplifie la lecture des API, la documentation, les exports JSON ou CSV. Les conventions de nommage deviennent un langage de liaison entre les couches du projet. La base de données, le serveur et le client parlent le même vocabulaire : ce que l’un écrit, l’autre comprend.

-- SQL
SELECT ch_user_id, ch_user_name FROM tab_users;

-- SQL
SELECT ch_user_id, ch_user_name FROM tab_users;

// PHP
$user = [ 'user_id' => 42, 'user_name' => 'Clara' ];

// PHP
$user = [ 'user_id' => 42, 'user_name' => 'Clara' ];

// JSON
{
  "user_id": 42,
  "user_name": "Clara"
}

// JSON
{
  "user_id": 42,
  "user_name": "Clara"
}

Dans ces trois syntaxes, le nommage reste stable et reconnaissable. Le passage d’un langage à l’autre devient intuitif, sans conversion mentale ni documentation superflue. Cette uniformité favorise la confiance et la compréhension dans un projet collectif.

Chaque développeur sait où trouver ce qu’il cherche, comment l’appeler, comment le transmettre. C’est cette continuité syntaxique, presque musicale, qui relie le code et lui donne sa force.

Arborescence et cohérence spatiale

L’organisation des dossiers et des fichiers participe à la même logique de cohérence que le nommage des champs ou des variables. L’arborescence est la carte du projet : elle raconte comment les éléments interagissent, où se situe la logique et comment le tout s’articule.

Chez Puce & Média, nous cherchons à ce que cette structure soit lisible d’un seul regard. Chaque dossier, chaque fichier porte un nom qui exprime sa fonction. L’ordre des répertoires reflète celui des étapes du traitement : la donnée, la logique, la présentation.

PROJECT_ROOT/
│
├── core/
│   ├── api/
│   │   ├── get_videos.php
│   │   └── save_sequence.php
│   └── includes/
│       └── __connect.php
│
├── modules/
│   └── training/
│   │   ├── video_training_view.php
│   │   ├── video_training_timeline.js
│   │   ├── video_training_controls.js
│   │   └── video_training_view.css
│   └── list/
│       ├── video_list_master.php
│       └── video_list_details.php
│
├── datas/
│   └── videos.json
│
└── index.php

PROJECT_ROOT/
│
├── core/
│   ├── api/
│   │   ├── get_videos.php
│   │   └── save_sequence.php
│   └── includes/
│       └── __connect.php
│
├── modules/
│   └── training/
│   │   ├── video_training_view.php
│   │   ├── video_training_timeline.js
│   │   ├── video_training_controls.js
│   │   └── video_training_view.css
│   └── list/
│       ├── video_list_master.php
│       └── video_list_details.php
│
├── datas/
│   └── videos.json
│
└── index.php

Cette hiérarchie permet de naviguer intuitivement : les API dans core/api, les scripts de logique dans modules, les fichiers front et serveur regroupés par module, partageant le même nom et différenciés uniquement par leur extension (.php, .js, .css). Le nom des répertoires reste en minuscule, séparé par des underscores, pour maintenir une lecture homogène sur tous les systèmes.

L’arborescence devient ainsi un langage spatial du code. Elle prolonge la syntaxe et renforce la compréhension : une structure claire aide à lire avant même d’ouvrir un fichier.

Langue et lisibilité : anglais, français ou mixte raisonné

La question du choix linguistique traverse naturellement tous nos projets. L’anglais s’impose souvent comme la langue du code, pour des raisons de compatibilité, d’héritage technique et de portée internationale. Pourtant, le français garde parfois sa légitimité, surtout lorsqu’il exprime plus justement une idée, une fonction ou un contexte d’usage.

Chez Puce & Média, nous privilégions une approche raisonnée. L’anglais est utilisé lorsqu’il simplifie la lecture ou garantit l’interopérabilité : user_name, match_datas, video_training_view. Mais le français conserve sa place lorsqu’il ancre la donnée dans une logique fonctionnelle ou locale : user_tel, ch_joueur_club, tab_matchs. L’important n’est pas la langue, mais la cohérence entre les champs, les scripts et les usages.

Les accents sont à proscrire : ils fragilisent la compatibilité entre systèmes et alourdissent les échanges. L’absence d’accent n’est pas une faute, mais un choix pragmatique. Ainsi, match_datas est préférable à match_donnees, même si le mot français serait plus juste sur le plan lexical. À l’inverse, user_tel reste plus clair et plus direct que user_phone, car il s’ancre dans la logique de l’application.

Tout est question de contexte et d’accord collectif. Dans une équipe, la lisibilité prime sur la pureté linguistique. Ce qui compte, c’est la compréhension commune : parler la même langue, celle du projet, celle du sens.

Sémantique, ontologie et sémiologie des identifiants

Ce dernier chapitre aborde la portée symbolique et structurelle du nommage : comment l’acte de nommer et la manière de l’écrire traduisent une pensée du code. Nommer, c’est donner du sens, mais aussi une forme. C’est une manière d’écrire le monde numérique, de lui imposer une grammaire et une lisibilité.

• Sémantique : chaque nom exprime une fonction, une intention, une relation. Un identifiant bien choisi ne se contente pas de nommer un élément, il indique ce qu’il fait exister dans le système. ch_user_id ou tab_options ne sont pas de simples labels, mais des indices de structure, des clés de lecture pour celui qui manipule ou relit le code.
• Ontologie : les conventions de forme, underscores, majuscules, préfixes et postfixes, dessinent une cartographie du monde numérique. Elles ordonnent les entités, distinguent les relations, organisent les dépendances. Par exemple, fk_user_club_id évoque à lui seul le lien entre un utilisateur et un club, là où un simple club_id perd ce contexte. La syntaxe devient ainsi une manière d’exprimer la hiérarchie du sens, de rendre visible la logique invisible du code.
• Sémiologie : la forme visuelle d’un identifiant porte du sens avant même sa lecture. L’œil distingue les majuscules, les coupures, les symboles. La simple alternance entre video_training (variable ou nom de fichier), videoTraining (fonction ou objet JS) et video-training (attribut ou classe CSS/HTML) change la perception de la relation entre les termes. Ce ne sont pas que des conventions : ce sont des signaux.
• Éthique du code : cette cohérence d’écriture n’est pas une esthétique, c’est une attention. Nommer correctement, c’est respecter le travail collectif, faciliter la relecture et la transmission. C’est écrire pour soi, mais aussi pour celui qui reprendra, corrigera, prolongera.

Ces conventions, ces signes, ces choix typographiques deviennent autant de repères partagés dans un écosystème vivant. C’est tout le principe que nous appliquons au sein de Pem’s Projects, où chaque nommage, chaque structure ou règle d’écriture favorise la compréhension mutuelle entre projets, applications et contributeurs. Le code cesse alors d’être un assemblage d’instructions : il devient un langage en soi, une manière de penser et de relier.

Conclusion

Ces conventions ne sont pas des règles figées, mais des chemins de cohérence que nous traçons pour mieux circuler dans nos projets. Nommer, structurer, écrire : chaque geste participe à un langage commun qui relie les idées, les outils et les personnes. Cette démarche ne s’arrête jamais. Elle évolue avec les pratiques, s’adapte aux besoins, se nourrit des retours d’usage. Ce n’est pas un système clos, mais une grammaire vivante qui continue de s’affiner à mesure que les projets s’enrichissent.

L’avenir de cette réflexion ne tient pas seulement dans le code, mais dans ce qu’il relie : la capacité à concevoir des structures compréhensibles, à écrire pour être lu, à penser le numérique comme un espace d’équilibre entre rigueur et liberté.