NULL vs NOT NULL : Une valeur vide en base de données MySQL

Il existe, dans le monde des bases de données, deux petits mots qui semblent insignifiants au premier abord : Null et Not Null. Pourtant, ce duo façon Yin et Yang décide de la qualité, de la cohérence et même de la fiabilité des applications que vous créez. Derrière ces termes se cachent des choix structurants qu’un développeur effectue parfois sans réfléchir, alors qu’ils influencent directement votre logique métier, vos futures requêtes SQL et la vie de vos utilisateurs. La valeur doit-elle être vide ou non-vide ?

• Comprendre clairement ce que signifient Null et Not Null afin de concevoir des bases de données plus fiables et éviter les erreurs silencieuses.
• Savoir choisir la bonne contrainte au bon moment pour gagner en cohérence métier, en lisibilité et en facilité de maintenance.
• Développer de meilleurs réflexes SQL pour éviter les pièges courants, renforcer la robustesse de vos requêtes et améliorer la qualité globale de vos applications.

Ce sujet paraît souvent technique, presque froid, mais il raconte en réalité une histoire très humaine : celle des données qui manquent, de celles que l’on croit posséder et de celles qui ne devraient jamais disparaître. Une fois que l’on comprend pourquoi Null existe et quand il devient dangereux, on commence à bâtir des bases de données MySQL plus propres, plus logiques, et surtout plus simples à maintenir dans le temps.

Si vous débutez avec MySQL ou que l’on ne vous a jamais vraiment expliqué la différence entre Null et Not Null, préparez-vous à un déclic. Ce tutoriel vous accompagnera pas à pas, dans un langage simple afin que vous sachiez enfin quand autoriser le vide… et quand l’interdire.

Comprendre ce que signifie réellement Null

Quand on découvre MySQL, on a tendance à penser que Null est juste une valeur vide, un champ texte sans caractères ou un zéro. C’est pourtant l’inverse. Null signifie littéralement que l’information est inconnue, absente, indéterminée. Ce n’est pas une case vide, c’est une case dont on ignore si elle aurait dû contenir quelque chose.

Pour bien saisir la nuance, imaginez une fiche client. Vous y voyez un champ « numéro de téléphone ». Si la personne n’en a pas donné, vous pourriez être tenté de mettre une chaîne vide. Pourtant, une chaîne vide indique qu’un numéro existe mais qu’il est vide… ce qui n’a pas de sens. Le Null, lui, exprime précisément que l’information n’a pas été fournie. Le système ne sait pas, et l’avoue honnêtement.

Cette différence paraît subtile mais elle éclaire des situations concrètes. Par exemple, si un utilisateur n’a pas encore choisi sa date de naissance parce qu’il vient de s’inscrire, Null vous permet de distinguer deux cas essentiels : la date n’a pas été renseignée, ou elle a été fournie mais invalidée.

Pourquoi Null pose parfois problème

Si Null fait peur, c’est parce qu’il ne se comporte comme rien d’autre. Il n’est pas égal à zéro, ni égal à une chaîne vide. Il n’est même pas égal à lui-même. Autrement dit, écrire NULL = NULL renvoie faux. Cette particularité provoque des surprises quand on commence à manipuler des requêtes. Une simple comparaison peut produire des résultats inattendus, voire des comportements qui semblent illogiques.

Imaginez une anecdote vécue par beaucoup de développeurs débutants. Un jour, vous lancez un SELECT * FROM users WHERE email != '' pour récupérer tous les utilisateurs qui ont un email renseigné. Vous vous attendez à obtenir la liste complète des utilisateurs ayant un email. Et pourtant, une partie manque. Pourquoi ? Parce que les enregistrements contenant Null ne passent pas ce test. Null n’est ni égal ni différent d’une chaîne vide, il est incomparable. C’est lui qui fait sa loi, et il s’en moque si cela perturbe votre logique.

C’est pour cette raison que beaucoup craignent son existence. Pourtant, Null n’est pas là pour nuire. Il est là pour éviter les interprétations erronées et préciser qu’une donnée manque. Son problème, c’est surtout quand on l’autorise n’importe où, ou quand on l’utilise comme cache-misère.

À quoi sert Not Null et pourquoi il est indispensable

À l’opposé de Null, on retrouve Not Null, une contrainte simple qui dit quelque chose de très important : ce champ doit toujours contenir une valeur. Il ne peut être ni vide ni inconnu. Not Null impose une règle stricte qui protège votre base de données MySQL contre les incohérences.

Dans une table utilisateurs, vous ne voudriez pas que le champ « email » soit Null si votre application repose sur l’envoi d’e-mails de confirmation. Not Null garantit que cette donnée existera toujours, ce qui vous évite des erreurs logiques ou des plantages sournois.

Dans d’autres cas, comme un identifiant unique, il serait même impensable d’autoriser Null. Imaginez un identifiant client Null. Comment le retrouver ? Comment le relier à une commande ? Comment l’afficher dans une liste ? Ce serait comme essayer de retrouver quelqu’un dans une foule sans connaître son nom, ni même son visage.

Not Null n’est donc pas là pour contraindre inutilement. Il protège la structure, impose une cohérence, et dit à la base de données : cette information est essentielle, vous ne devez jamais créer un enregistrement sans elle.

Le piège courant : mettre Not Null partout

Quand on découvre Not Null, on a parfois envie de l’appliquer à tous les champs, comme pour se protéger d’erreurs. Après tout, moins il y a de Null, plus la base semble propre. Pourtant, forcer des valeurs là où l’absence aurait du sens crée plus de problèmes que cela n’en résout.

Prenons l’exemple d’un champ « date de paiement » dans une table de factures. Si le paiement n’a pas encore été effectué, vous êtes tenté d’inscrire une valeur par défaut comme « 0000-00-00 ». Ce choix est dangereux. Il fait croire que la date existe, alors qu’elle est fictive. Plus tard, vous devrez filtrer ce faux zéro, et vous créerez de la confusion inutile.

Null, dans ce cas, transmet une information capitale : le paiement n’a pas encore eu lieu. Forcer une valeur par défaut n’est pas une solution, c’est plutôt une dissimulation.

Quand autoriser Null devient le bon choix ?

Il existe des situations très précises où Null devient la meilleure option. Il est parfaitement légitime pour exprimer une donnée manquante, facultative ou pas encore définie. Il raconte quelque chose que Not Null ne sait pas raconter.

Un champ remarque, une seconde adresse, un numéro de téléphone supplémentaire, une date de fin de contrat encore inconnue… tous ces éléments sont optionnels. Null permet d’exprimer clairement leur caractère facultatif. Laisser ce vide devient presque une information en soi.

Imaginez que vous créiez un formulaire d’inscription. Certains champs ne seront jamais obligatoires, car ils ne conditionnent pas l’accès au service. Les forcer reviendrait à forcer l’utilisateur à inventer une information pour contourner votre formulaire. Null vous évite ces contorsions.

Comment Null influence vos requêtes MySQL

Null entraîne parfois des comportements déroutants lorsque vous commencez à rédiger vos requêtes. Il faut imaginer Null comme une zone d’ombre. Dès qu’une comparaison touche cette zone, MySQL préfère lever les mains et déclarer « je ne peux pas comparer ». Ce fonctionnement peut surprendre, surtout lorsque l’on compare Null à des valeurs classiques.

Si vous essayez de filtrer des résultats avec une simple comparaison, comme WHERE age > 18, tous les enregistrements où l’âge est Null seront ignorés. Ils ne seront ni vrais ni faux. Ils resteront suspendus, cachés derrière un rideau. Pour les récupérer, il faudra utiliser la syntaxe WHERE age IS NULL.

Ce petit détail change tout. Beaucoup de débutants découvrent cette subtilité à leurs dépens, en se retrouvant avec des résultats incomplets sans comprendre pourquoi.

Il faut donc apprendre à manier Null avec précaution. Si vous souhaitez inclure des données manquantes dans vos calculs, vos tris ou vos regroupements, vous devrez toujours penser à le préciser. Le simple fait de savoir que Null ne se compare à rien vous évitera d’innombrables erreurs silencieuses, celles que l’on découvre parfois trop tard, lorsque le projet est déjà en production.

Quelques erreurs fréquentes que Null provoque chez les débutants

Une erreur très répandue consiste à croire que deux Null peuvent être égaux. Pourtant, comme évoqué plus haut, Null n’est jamais égal à Null. Il n’exprime pas une valeur, il exprime l’absence de valeur. Dire que deux absences sont égales n’a pas de sens pour MySQL.

Une autre confusion courante consiste à filtrer des valeurs manquantes en utilisant = '', ce qui ne fonctionnera jamais. Cette erreur provoque souvent des situations étranges. Par exemple, chercher les utilisateurs « sans email » et obtenir un résultat vide, alors que la base en contient des dizaines. Dès que l’on comprend que Null doit être testé avec IS NULL, les choses deviennent beaucoup plus logiques et prévisibles.

Enfin, certains développeurs tentent de trier des listes contenant Null sans s’attendre à ce que la base de données place parfois ces éléments en premier, parfois en dernier, selon le système ou les options. Cela peut donner l’impression que la base agit de manière capricieuse. En réalité, elle applique simplement ses propres règles de tri.

Comment choisir entre Null et Not Null : une méthode simple et fiable

Pour déterminer si un champ doit autoriser Null ou non, il existe une approche que beaucoup de développeurs expérimentés appliquent sans même y penser. Elle repose sur une seule question :

Cette information est-elle indispensable pour que l’enregistrement ait un sens ?

Si la réponse est oui, alors Not Null s’impose naturellement. Sans cette information, la ligne serait incomplète, incohérente, voire inutilisable. C’est le cas typique d’un identifiant, du nom d’un produit, du prix d’un article ou de tout autre élément essentiel à votre logique métier.

Si la réponse est non, si l’absence de cette donnée ne compromet pas la cohérence de l’enregistrement, alors Null devient acceptable. Il décrit une réalité : certaines informations sont facultatives, évolutives, ou simplement inconnues au moment de l’enregistrement.

Cette méthode intuitive vous aide à structurer vos tables avec cohérence. Elle vous évite de recourir à des valeurs artificielles comme « N/A », « 0 » ou des dates fantômes. Elle renforce également la clarté de vos modèles, ce qui facilitera votre travail sur le long terme.

Null, un allié pour comprendre le cycle de vie d’une donnée

Chaque donnée stockée en base a une vie propre. Certaines naissent dès la création de l’enregistrement, d’autres apparaissent plus tard, lorsqu’une action est effectuée. Null permet justement de révéler ces étapes.

Prenons l’exemple d’une commande sur un site e-commerce. Lors de sa création, une commande ne possède aucune date d’expédition, car le produit n’a pas encore quitté l’entrepôt. Utiliser Null dans ce cas raconte très bien la situation. La commande existe, mais elle n’est pas encore traitée. Plus tard, lorsque la date sera renseignée, l’évolution apparaîtra naturellement.

Not Null, ici, serait illogique. On ne peut pas forcer une date d’expédition pour une commande qui vient seulement d’être passée. On pourrait certes mettre une date fictive, mais cela polluerait le modèle de données et introduirait des ambiguïtés.

Null aide donc à suivre l’évolution d’une information. Il dit : « cette donnée arrivera peut-être plus tard ». Et cela reflète souvent la réalité du métier. Beaucoup de développeurs confirment qu’après quelques années de pratique, ils interprètent Null non plus comme un vide, mais comme un état intermédiaire.

Pourquoi certains développeurs préfèrent réduire au maximum les Null

Il existe un courant de pensée, plutôt pragmatique, qui conseille de limiter l’usage de Null. L’argument principal est simple : moins il y a de cas particuliers, plus la logique est facile à maintenir. Null oblige à écrire des conditions supplémentaires, à multiplier les tests, à envisager des scénarios alternatifs.

Certains frameworks, comme ceux orientés objets, préfèrent même créer des valeurs par défaut pour éviter les Null. Par exemple, un nombre pourrait avoir la valeur 0 plutôt que Null, ou une chaîne vide plutôt qu’une donnée absente.

Mais cette philosophie a une limite. Elle fonctionne bien pour des données purement techniques, mais devient dangereuse dès qu’elle masque une réalité métier. En supprimant Null, on risque d’interpréter à tort une donnée qui manque. Il faut donc trouver un équilibre entre clarté et précision.

Le moment où Not Null devient indispensable

Même si Null a toute sa place dans une base de données, il existe des situations où Not Null doit absolument être imposé. C’est notamment le cas lorsque l’absence d’une valeur empêcherait votre application de fonctionner correctement.

Des formations informatique pour tous !

Débutant ou curieux ? Apprenez le développement web, le référencement, le webmarketing, la bureautique, à maîtriser vos appareils Apple et bien plus encore…

Formateur indépendant, professionnel du web depuis 2006, je vous accompagne pas à pas et en cours particulier, que vous soyez débutant ou que vous souhaitiez progresser. En visio, à votre rythme, et toujours avec pédagogie.

Découvrez mes formations Qui suis-je ?

Prenons un exemple très concret : le mot de passe d’un utilisateur. Impossible d’imaginer autoriser Null ici. Même si votre système utilise un hash, même si vous appliquez une politique de connexion externe ou un SSO, vous ne pouvez pas créer un compte sans un identifiant solide. Sans cette contrainte, votre base de données MySQL perd toute logique. Un utilisateur sans mot de passe serait comme une clé sans serrure.

Un autre exemple tout aussi parlant concerne les relations entre tables. Dans une table de commandes, la colonne indiquant l’ID du client doit forcément être Not Null. Une commande sans client n’a aucun sens. Elle deviendrait orpheline, impossible à rattacher, et inutile à analyser.

Dans ce type de cas, Not Null agit comme une règle d’hygiène. Il évite des scénarios absurdes et garantit que vos enregistrements possèdent au minimum ce qui est nécessaire pour exister. On pourrait presque dire que Not Null impose la cohérence, là où Null exprime l’incertitude.

Comment Null et Not Null influencent les validations côté application

L’erreur courante chez les débutants consiste à croire que les validations côté application suffisent. Ils se disent qu’un formulaire empêchera de toute façon l’envoi d’une donnée vide, alors pourquoi ajouter une contrainte en base ? Ce raisonnement paraît logique, mais il crée souvent des failles.

Une application évolue, les formulaires changent, les API s’ouvrent, des imports automatisés apparaissent. Ce qui était impossible un jour peut devenir possible le lendemain. Une base non protégée par des Not Null bien placés peut alors commencer à accumuler des enregistrements incomplets sans que personne ne s’en aperçoive immédiatement.

À l’inverse, une base correctement structurée n’acceptera jamais une donnée incohérente, même si un développeur oublie une validation. Elle devient un garde-fou qui sécurise tout le cycle de vie de votre application.

Null aussi demande une réflexion côté application. Lorsque vous recevez une donnée Null depuis la base, votre logique doit être préparée à l’interpréter correctement : un champ vide ne se traite pas comme une valeur zéro ; une date Null ne se formate pas comme une date valide ; et un texte Null n’est pas une chaîne vide.

C’est cette compréhension mutuelle entre l’application et la base de données qui rend votre système à la fois robuste et prévisible.

Null dans les calculs : un comportement à connaître absolument

Dans les calculs, Null peut devenir un invité perturbateur. Additionner une valeur Null, multiplier par Null, diviser par Null, tout cela renverra Null. C’est comme si un simple point d’ombre empêchait toute opération d’être évaluée.

Pour contourner ce comportement, SQL propose plusieurs solutions, dont la fonction COALESCE, extrêmement utile. Elle permet de remplacer Null par une valeur de votre choix lorsqu’un calcul l’exige. Par exemple, COALESCE(prix_reduction, 0)indiquera que s’il n’y a pas de réduction, elle sera considérée comme zéro.

Cette technique préserve l’intention métier tout en permettant aux calculs de continuer à fonctionner. On évite ainsi des résultats qui s’effondrent à cause d’une seule donnée manquante.

Beaucoup de développeurs expérimentés utilisent cette fonction presque quotidiennement, car elle exprime très bien une logique simple : si une donnée est inconnue, utilisez plutôt celle-ci. C’est une manière élégante de travailler avec Null sans jamais le subir.

Quand Null améliore réellement la lisibilité des données

Il y a des situations où Null rend vos tables plus claires, plus propres, et plus lisibles. Imaginez une table qui contient des tâches à effectuer. Certaines tâches auront une date de réalisation, d’autres non. Mettre Null pour celles qui ne sont pas encore terminées permet de repérer immédiatement l’état d’avancement. Aucun code spécial, aucune valeur fantaisiste, simplement une absence qui raconte une histoire.

On retrouve ce genre de logique dans les systèmes de réservation, les plannings, les processus industriels ou les outils de suivi. Une colonne Null est souvent plus parlante qu’un texte comme « en attente » ou une date fictive.

En d’autres termes, Null permet d’utiliser la base comme un miroir fidèle de la réalité. Il permet de représenter non seulement ce que l’on sait, mais aussi ce que l’on ne sait pas encore. L’information devient complète, même si elle est partiellement vide.

Les fausses solutions à éviter absolument

Certaines pratiques courantes trahissent une mauvaise compréhension de Null. Elles créent plus de problèmes qu’elles n’en résolvent. Parmi les plus fréquentes, on retrouve l’usage de valeurs sentinelles, comme « 0000-00-00 », « -1 », « 999 », ou encore la célèbre chaîne « N/A ».

Ces valeurs artificielles contaminent la base. Elles faussent les calculs, polluent les statistiques, provoquent des tris absurdes et rendent vos requêtes plus difficiles à écrire. En réalité, elles ne servent qu’à contourner une mauvaise conception initiale.

Une base de données doit refléter la vérité métier, pas une vérité maquillée. Null est la seule manière propre de dire « cette information n’existe pas pour l’instant ».

Lors d’un projet collaboratif, un développeur avait choisi de remplacer toutes les valeurs Null par « 0 », persuadé que cela simplifierait les contrôles. Pendant plusieurs mois, tout s’est bien passé, jusqu’au jour où l’équipe a voulu générer des statistiques sur les produits renvoyés par les clients.

Le problème ? Le zéro signifiait parfois « aucune donnée », parfois « quantité réelle égale à zéro ». Les deux significations étaient fusionnées. Impossible de distinguer ce qui n’avait jamais été renseigné de ce qui avait bel et bien été évalué.

L’équipe a passé une journée entière à nettoyer la base, reconstituer les données et corriger des formulaires. Tout cela aurait pu être évité en autorisant simplement Null là où sa présence était logique. Cette anecdote rappelle qu’une petite facilité peut devenir une grande source de confusion.

Null et les bases relationnelles modernes

Contrairement à ce que certains imaginent, Null n’est pas un vestige du passé. Les bases modernes comme PostgreSQL, MySQL, MariaDB ou SQL Server s’appuient toutes sur lui pour représenter les données manquantes.

Toutes fournissent des outils pour mieux le manipuler : fonctions dédiées, opérateurs spécialisés, options de tri, règles de contraintes, comportements configurables. Null n’est pas une contrainte que l’on essaie de tolérer, mais une partie intégrante du modèle relationnel.

Les développeurs qui le comprennent deviennent automatiquement meilleurs, non seulement dans l’écriture de requêtes, mais aussi dans la conception de schémas de données. Ils anticipent les cas limites, évitent des erreurs de logique et créent des structures agréables à maintenir, même plusieurs années plus tard.

Comment documenter vos choix pour éviter les malentendus

Une bonne pratique souvent négligée consiste à expliquer pourquoi un champ autorise Null ou non. Cette documentation peut prendre plusieurs formes : un commentaire directement dans le schéma SQL, une note dans le fichier de migration, ou une page interne qui explicite la logique métier.

Cette simple habitude facilite la vie de toute l’équipe. Un développeur arrivant en cours de projet comprendra immédiatement la raison d’être d’un Null. Il saura que telle date est optionnelle parce qu’elle apparaît seulement en fin de processus, ou qu’un champ est Not Null parce qu’il représente une donnée fondatrice. Documenter ces choix permet d’éviter les interprétations hasardeuses et les modifications malheureuses.

Et même si vous travaillez seul, cette documentation vous aidera. Dans trois mois, vous aurez peut-être oublié pourquoi un champ ne peut pas être vide. Une annotation claire vous épargne alors une longue séance d’archéologie numérique.

Synthèse conceptuelle : Null et Not Null comme langage

Lorsque l’on prend du recul, Null et Not Null deviennent plus que de simples contraintes techniques. Ce sont des mots qui composent le langage de votre base de données. Ils décrivent ce que vous savez, ce que vous ignorez, et ce que vous refusez d’ignorer.

Null exprime une nuance, un doute, un manque temporaire ou durable. Not Null pose un cadre, fixe un socle, donne un sens impératif aux données. Les deux coexistent parce qu’ils servent tous les deux une vérité métier.

L’erreur la plus fréquente consiste à les utiliser par habitude, sans réfléchir à ce qu’ils racontent. En réalité, chaque utilisation de Null doit être intentionnelle, réfléchie, guidée par un besoin métier clair. Chaque Not Null doit être justifié par un impératif logique. Lorsque ces décisions deviennent conscientes, la qualité de votre modèle relationnel s’améliore immédiatement.

Le juste milieu : une base solide, mais flexible

Trouver l’équilibre entre Null et Not Null demande parfois de l’expérience, mais vous pouvez déjà développer de bons réflexes.

• Si une donnée est essentielle, irremplaçable, liée à l’identité ou à l’intégrité d’un enregistrement, alors Not Null s’impose naturellement.
• Si une donnée est optionnelle, évolutive, contextuelle, ou liée à des étapes futures d’un processus, alors Null devient un allié cohérent et explicatif.

Cet équilibre vous évite les dérives courantes :

• trop de Null qui rendent les requêtes difficiles à lire
• trop de Not Null qui obligent à inventer de fausses valeurs.

Une bonne base est une base honnête, une base qui reflète la réalité sans artifices. Et c’est précisément cela qu’offre une bonne compréhension du Null. Ce n’est pas du vide, c’est un état. Un état légitime, parfois utile, parfois crucial.

En découvrant les notions de Null et Not Null, on a souvent l’impression d’entrer dans un sujet abstrait réservé aux spécialistes. Mais en réalité, ces deux concepts racontent simplement comment une base de données exprime la présence ou l’absence d’une information. Ce sont deux outils complémentaires qui, bien employés, transforment vos tables en représentations fidèles de votre logique métier.

• Comprendre Null, c’est accepter que certaines données n’existent pas encore, ou n’existeront peut-être jamais.
• Comprendre Not Null, c’est affirmer que certaines informations sont indispensables.

En choisissant consciemment entre l’un et l’autre, vous créez un modèle fiable, prévisible, facilement maintenable. Et au passage, vous vous épargnez ces bugs silencieux qui peuvent ruiner une journée entière de travail.

La maîtrise de ce duo vous accompagnera tout au long de votre parcours de développeur. Plus vous avancerez, plus vous verrez que ces choix, qui paraissaient au départ purement techniques, deviennent un véritable langage pour dialoguer avec votre base. Un langage clair, précis, capable de refléter la réalité des applications que vous construisez.

Si vous deviez retenir une seule idée, ce serait celle-ci : Null et Not Null ne sont pas des contraintes, ce sont des décisions. Et chaque décision construit la robustesse de votre application. En les comprenant, vous posez les fondations d’un code plus propre, plus durable et bien plus agréable à faire évoluer.

Alban

Fondateur de l’agence Créa-troyes, affiliée France Num
Intervenant en Freelance.
Contactez-moi

crea-troyes.fr