Une vraie plateforme se construit en quatre étapes, dans cet ordre : les besoins, le modèle de données, le backend sécurisé, puis l'interface. Taper du code, c'est surtout la quatrième étape.
Sauter une étape ne fait pas gagner de temps. Le problème revient plus tard sous sa forme la plus coûteuse, souvent une réécriture.
Ce guide explique chaque étape simplement, ce qui rate à chacune, et ce qui change quand on construit pour une entreprise algérienne.
Quelles sont les 4 étapes pour construire une plateforme web ?
Pensez à la construction d'une maison. D'abord, on décide des pièces nécessaires. Puis on coule les fondations.
Ensuite viennent les murs, l'électricité et les serrures. Seulement après, on peint et on meuble. Personne ne peint avant que les fondations soient sèches.
| Étape | En mots simples | Version maison | Ce qui rate si on la saute |
|---|---|---|---|
| 1. Besoins | Ce que la plateforme doit faire, et ce qu'on coupe | Choisir les pièces | Un produit très en retard, rempli de fonctions inutiles |
| 2. Modèle de données | Comment l'information est stockée et reliée | Les fondations | Chaque étape suivante hérite des dégâts |
| 3. Backend sécurisé | Règles, sécurité et paiements côté serveur | Murs, électricité, serrures | N'importe qui change les prix ou lit les données des autres |
| 4. Interface | Les écrans pour les clients et pour le patron | Peinture et meubles | Le patron ne peut rien faire sans le développeur |
Les projets meurent rarement d'un mauvais code. Ils meurent d'un modèle de données qui ne colle pas à l'activité. Ou d'une liste de fonctions jamais coupée, ou d'un patron incapable de gérer seul sa plateforme.
Comment rédiger les besoins d'une plateforme ?
Le but n'est pas d'écrire tout ce que veut le client. C'est de trouver les quelques fonctions qui portent l'activité, et de couper le reste.
Un premier rendez-vous produit souvent une longue liste de souhaits, parfois des dizaines de fonctions. En général, seule une poignée compte le jour du lancement.
Tout construire ne donne pas au client un produit plus riche. Ça lui donne un produit livré bien plus tard, qui cache les fonctions importantes sous des menus.
La bonne question n'est pas « vous voulez ça ? », car la réponse est toujours oui. C'est « si ça n'existait pas le jour du lancement, qu'est-ce qui casserait ? »
La plupart des fonctions résistent mal à cette question, et c'est le but.
Pourquoi le modèle de données est-il l'étape la plus importante ?
Parce que le code coûte peu à changer, et une base pleine de vraies données clients beaucoup. La changer, c'est migrer les données et mettre à jour chaque application qui les lit.
Les mêmes erreurs reviennent sans cesse :
- Stocker l'état actuel au lieu de ce qui s'est passé. L'historique est détruit.
- Stocker l'argent en nombres décimaux. Des erreurs d'arrondi s'infiltrent. Utilisez des entiers en centimes.
- Oublier la relation sur laquelle tourne vraiment l'activité. Elle sera bricolée plus tard.
- Optimiser trop tôt pour un problème de vitesse qui n'existe pas.
Six mois plus tard, le symptôme est toujours le même : les questions simples du patron deviennent lentes ou impossibles.
De quoi a besoin un backend sécurisé ?
Le backend, c'est la partie de la plateforme qui tourne sur le serveur, hors de vue. Une règle compte plus que tout : c'est le serveur qui décide, jamais le navigateur. Tout ce qu'envoie le navigateur peut être falsifié. Si un navigateur peut dire à votre serveur quel prix facturer, vous n'avez pas de backend, vous avez une boîte à idées.
En pratique :
- Utilisez la sécurité au niveau des lignes. C'est une fonction de la base qui décide quelles lignes chaque utilisateur voit ou modifie, pour qu'une clé volée ne lise pas les commandes d'un autre vendeur (documentation PostgreSQL).
- Faites les opérations sensibles en une seule étape. Baisser le stock et créer la commande se font ensemble, dans une seule transaction, pour que deux acheteurs n'obtiennent pas le dernier article.
- Ne laissez jamais modifier les écritures financières. Les corrections sont de nouvelles écritures. J'explique pourquoi dans ne modifiez jamais une écriture financière.
Pourquoi chaque plateforme a-t-elle besoin d'un back-office ?
Parce qu'une plateforme a deux publics, et le second est souvent oublié. Les clients ont besoin de la boutique. Le patron a besoin d'un back-office pour faire son travail sans vous appeler.
C'est-à-dire changer un prix, rembourser une commande, suspendre un utilisateur, lire les chiffres de la veille.
Un back-office n'est pas un bonus. C'est la différence entre une plateforme que le client possède et une qu'il loue à votre numéro de téléphone.
Quand un modèle tout fait suffit-il, et quand faut-il du sur-mesure ?
| Modèle tout fait | Plateforme sur mesure | |
|---|---|---|
| Coût le premier jour | Très faible | Plus élevé |
| Adéquation à l'activité | Générale, pour tout le monde | Construite autour du vrai fonctionnement |
| Paiement à la livraison | Ajouté plus tard, si jamais | Le parcours principal |
| Liens avec les livreurs | Une extension qui peut être abandonnée | Connexion directe au livreur |
| Arabe de droite à gauche | Souvent cassé dans le thème | Prévu dès le départ |
| Quand vous grandissez | Vous le dépassez et recommencez | Vous l'étendez |
La version honnête : pour un petit commerce avec quelques articles, un bon modèle tout fait suffit. Je le dis aux clients.
Le sur-mesure devient rentable quand le fonctionnement est l'activité, comme le paiement à la livraison avec livreurs et plusieurs vendeurs. J'explique ce choix dans logiciel sur mesure ou standard.
Qu'est-ce qui change quand on construit une plateforme pour l'Algérie ?
Les besoins. Les clients demandent souvent les fonctions d'une entreprise bien plus grande, parce que c'est ce qu'ils ont vu. Le travail n'est pas de dire non, mais d'ordonner : sortir d'abord ce qui rapporte. Un patron déjà échaudé ne croira pas un plan sur douze mois, mais il croira une page de commande qui marche en quelques semaines.
Le modèle de données. Une commande algérienne est une suite d'événements sur plusieurs jours : passée, confirmée par téléphone, confiée au livreur, en livraison, tentative ratée, deuxième tentative, livrée, encaissée, reversée par le livreur en fin de semaine moins ses frais.
Stockez-la en une ligne avec un statut écrasé sans cesse, et vous ne pourrez pas vérifier le versement hebdomadaire du livreur. Wilaya et commune doivent être de vraies tables de référence, pas du texte libre, car le prix de livraison en dépend.
Le backend. La plupart des paiements sont des espèces encaissées à la porte par quelqu'un qui ne travaille pas pour vous. Le plus dur est de comparer les encaissements attendus avec ce que le livreur reverse vraiment. Chargily mérite d'être ajouté pour le paiement en ligne, mais faire du prépaiement le parcours principal, c'est construire pour un client qui n'est pas encore là.
L'interface. Le vendeur utilise un Android de milieu de gamme, en arabe, de droite à gauche, avec une connexion qui coupe. Testez sur un vrai appareil. Et le back-office compte encore plus ici, car l'alternative, c'est un client qui vous appelle à 21 h pour changer un prix.
Quelles erreurs font les projets de plateforme ?
- Construire chaque fonction demandée. Coupez jusqu'à ce qui casse l'activité si ça manque.
- Écrire du code avant de dessiner le modèle de données.
- Faire confiance au navigateur pour les prix ou les droits.
- Laisser le back-office « pour plus tard ».
- Tester seulement sur un ordinateur, alors que les utilisateurs sont sur des téléphones moyens.
Que faire cette semaine ?
- Aujourd'hui : écrivez votre liste de fonctions, puis marquez seulement ce qui casse le lancement si ça manque.
- Cette semaine : dessinez votre modèle de données : les choses principales que vous stockez et comment elles se relient.
- Cette semaine : pour chaque table, décidez : est-ce un fait du passé, ou un état actuel ?
- Avant de construire les écrans : listez ce que le patron doit faire seul chaque jour dans le back-office.
- À chaque étape : montrez au client un morceau qui marche, expliqué en phrases simples.
Si vous débutez et que le budget vous inquiète, lisez pourquoi les applis chères meurent avant leur lancement.