Quand votre appli créée avec l'IA a-t-elle vraiment besoin d'une base de données (et quand n'en a-t-elle pas besoin) ?

Que fait vraiment une base de données ?

Le seul rôle d’une base de données est de garantir que deux personnes ne puissent pas accidentellement écraser ou détruire le travail de l’autre en utilisant la même appli — la vitesse, la structure et les recherches complexes ne sont que des effets secondaires de la résolution de ce problème unique.

Vous avez créé votre appli avec l’IA. Elle fonctionne. Elle enregistre les données dans des fichiers ou une feuille de calcul. Tout semble aller bien.

Puis l’une de ces deux choses se produit :

Votre appli ralentit un peu plus à chaque utilisation.
Deux utilisateurs essaient de s’en servir en même temps et quelque chose casse.

Aucun de ces deux échecs n’est évident avant qu’il ne soit trop tard. Ce sont tous les deux des problèmes de base de données déguisés.

Si vous utilisez encore des fichiers ou des feuilles de calcul, vous n’avez probablement pas encore besoin de base de données. Et c’est très bien ainsi. Mais vous devez connaître les signes avant-coureurs indiquant que vous allez bientôt en avoir besoin.

Quand est-il acceptable d’utiliser de simples fichiers plutôt qu’une base de données ?

Les fichiers fonctionnent très bien tant que vous êtes le seul utilisateur de l’appli et que les modifications sont rares — c’est tout le test à faire.

Le site portfolio d’un freelance ? Les fichiers sont parfaits. Un suivi personnel de dépenses ? Les fichiers conviennent tout à fait. Un projet perso avec un seul utilisateur ? Ne compliquez pas les choses inutilement.

Les vrais signes que les fichiers font l’affaire :

Une seule personne utilise l’appli à la fois (ou les utilisateurs sont hors ligne pendant que d’autres travaillent).
Vous mettez rarement les données à jour (une fois par jour, une fois par semaine, une fois par mois).
Perdre les 30 dernières secondes de travail est acceptable (votre builder peut simplement réessayer).
Le fichier de données est assez petit pour être envoyé par email (moins de 10 Mo).

Si ces quatre points sont vrais, restez sur les fichiers. Sérieusement. La simplicité est un atout, pas une limitation.

Pourquoi mon appli créée avec l’IA ralentit-elle ?

Votre appli ralentit parce que le fichier dans lequel elle enregistre les données ne cesse de grossir, et que votre builder charge le fichier entier en mémoire à chaque fois qu’il doit modifier quoi que ce soit — un coût à peine perceptible au début, mais qui devient pénible à mesure que le fichier grossit.

Vous le remarquez d’abord comme une impression. Votre appli semble plus lente qu’avant. Cliquer sur un bouton prend une seconde de plus. Les recherches sont visiblement plus lentes. Vous n’avez pourtant rien changé au code — alors pourquoi est-ce plus lent ? Voici le schéma :

L’appli charge le fichier de données complet (100 lignes, rapide).
Un utilisateur ajoute un enregistrement (101 lignes maintenant).
L’appli relit le fichier entier pour vérifier (toujours rapide).
Après 2 000 enregistrements, lire le fichier prend 2 secondes.
Après 10 000 enregistrements, cela prend 20 secondes.

Ce n’est pas exponentiel, mais cela devient perceptible autour de 5 000 enregistrements et pénible autour de 20 000.

Première solution (avant d’ajouter une base de données) : demandez à votre builder de charger les données à la demande. Ne charger que les enregistrements affichés, ou seulement les colonnes visibles. De nombreuses applis peuvent rester sur des fichiers en étant simplement plus intelligentes sur ce qu’elles chargent.

Quand passer à une base de données : vous avez plus de 50 000 enregistrements de données, ou la lenteur persiste même après avoir optimisé les chargements.

Pourquoi mon appli a-t-elle perdu des données quand deux personnes l’ont utilisée en même temps ?

Cela arrive parce que deux personnes peuvent modifier le même fichier en même temps et que l’appli n’a aucun moyen de le savoir — quiconque enregistre en second l’emporte, et les modifications de la première personne disparaissent silencieusement. On appelle cela une « écriture concurrente », et c’est un bug classique de perte de données.

Les deux personnes voient leurs propres modifications sur leur écran. Elles cliquent toutes les deux sur « enregistrer ». Vous saurez que c’est en train de se produire si :

Des utilisateurs signalent de temps en temps des données manquantes (surtout si plusieurs personnes sont dans l’appli en même temps).
Des utilisateurs signalent voir les modifications d’autres personnes « annulées » sans explication.
Deux utilisateurs modifient le même enregistrement et les modifications de l’un d’eux disparaissent.
Vous recevez des messages du type « je jure que j’ai ajouté ça hier et maintenant ce n’est plus là ».

Ce n’est pas la faute de l’appli. C’est une limite propre au fonctionnement des fichiers. Il n’existe pas de bonne façon de gérer cela sans base de données.

Quand passer à une base de données : dès que deux personnes utilisent l’appli en même temps, même si le problème ne s’est pas encore produit.

Pourquoi mon appli ne peut-elle pas gérer des recherches complexes avec des fichiers ?

Parce qu’avec des fichiers, votre builder doit charger et filtrer chaque ensemble de données lié à la main, étape par étape, au lieu de poser une seule question et d’obtenir une seule réponse — une base de données fait le même travail en quelques millisecondes avec une seule requête.

Disons que vous voulez trouver « toutes les factures impayées des clients en Californie qui n’ont pas été contactés au cours de la dernière semaine ». Avec des fichiers, votre builder doit :

Charger toutes les factures.
Filtrer celles où impayé = vrai.
Charger tous les clients et faire correspondre par ID.
Filtrer sur état = « CA ».
Charger tous les enregistrements de contact et faire correspondre par ID client.
Filtrer sur date > il y a plus d’une semaine.

Avec une base de données, vous écrivez une seule requête et elle fait tout cela en quelques millisecondes.

Quand passer à une base de données : quand votre builder vous dit « il faudrait que j’écrive du code sur mesure pour répondre à cette question ». Ou quand vous remarquez que l’appli travaille énormément juste pour vous afficher des données filtrées.

Que dois-je dire à mon builder quand j’ai besoin d’une base de données ?

Expliquez-lui simplement ce qui ne va pas et demandez-lui un plan — quelque chose comme : « L’appli [ralentit / a perdu des données / a besoin de recherches plus complexes]. Je pense qu’on devrait ajouter une base de données. C’est un gros changement ? »

La plupart des builders peuvent faire passer une appli des fichiers à une base de données en 1 à 2 jours pour les petites applis, quelques jours pour les plus grosses. Le processus est le suivant :

Garder l’appli globalement identique (les utilisateurs ne verront pas de grand changement).
Brancher un backend de base de données (cela ressemble toujours à des fichiers pour le reste du code, mais c’est une base de données en dessous).
Tester à fond (car déplacer des données est une opération sensible).
Faire tourner les deux en parallèle pendant une semaine jusqu’à ce que vous soyez sûr que tout va bien.

Le builder pourrait vous demander :

« On utilise PostgreSQL, MySQL, ou autre chose ? »
- Votre réponse : « Ce avec quoi tu es le plus à l’aise. Je ne connais pas la différence, mais je te fais confiance. »
« Ça va prendre 3 jours. Ça en vaut la peine ? »
- Votre réponse : « Si on doit migrer de toute façon, mieux vaut le faire tôt, avant qu’il y ait encore plus de données. »
« Faut-il migrer les anciennes données ? »
- Votre réponse : « Oui, sauf s’il y a moins de 100 enregistrements, auquel cas repartir de zéro convient très bien. »

Dois-je comprendre les bases de données moi-même ?

Non — vous n’avez pas besoin de savoir ce qu’est une base de données, d’apprendre le SQL, ni de comparer PostgreSQL et MySQL. Tout ce que vous avez à dire à votre builder, c’est : « Deux personnes doivent pouvoir utiliser l’appli en même temps sans perdre le travail de l’autre. »

C’est tout. Votre builder peut choisir la base de données. Une solution simple comme SQLite (pour une appli personnelle ou d’équipe avec moins de 10 utilisateurs simultanés) ou PostgreSQL (pour tout ce qui est plus important) fait très bien l’affaire dans les deux cas.

Comment savoir si mon appli a besoin d’une base de données ?

Cochez celles de ces quatre affirmations qui vous concernent — deux cases cochées ou plus signifient qu’il est temps d’ajouter une base de données dès maintenant.

Lenteur : l’appli était plus rapide il y a 3 mois, elle est plus lente maintenant. Le fichier de données fait plus de 20 Mo ou contient plus de 10 000 enregistrements.
Perte de données : les modifications de quelqu’un ont disparu, ou plusieurs utilisateurs ont signalé des modifications manquantes.
Complexité : vous voulez poser des questions du type « montre-moi X filtré par Y » et le builder répond que « c’est difficile à faire avec des fichiers ».
Utilisateurs : plus d’une personne utilise l’appli en même temps (même occasionnellement).

Si vous avez coché deux cases ou plus, votre appli est prête pour une base de données.

Si vous n’avez coché aucune case, vos fichiers conviennent très bien. Gardez-les. La simplicité a de la valeur.

Si vous avez coché une seule case, demandez à votre builder : « Est-ce assez rapide pour tenir encore 6 mois comme ça ? » Si oui, attendez. Si non, migrez maintenant.