On code pour la production, jamais pour la démonstration.
Aucun affichage de mise au point ne survit à la livraison, aucune valeur codée en dur « pour l'instant ». Ce qui part en ligne est ce qui sera relu dans trois ans.
L'atelier · Thiry Adrien · Luxembourg · Belgique · France
Un seul interlocuteur, du relevé à la mise en service.
Pas d'équipe commerciale qui promet, de chef de projet qui traduit, puis de développeur qui découvre. La personne qui vous écoute est celle qui écrit le code, et celle qui répondra dans deux ans quand la loi aura changé.
Les règles de l'atelier
Cahier des charges interne
Les requêtes sont préparées. Toutes. Sans exception.
Une seule concaténation de chaîne dans une requête suffit à ouvrir la base entière. Il n'y en a aucune — c'est vérifiable ligne par ligne, pas une déclaration d'intention.
Tout ce qui sort à l'écran est échappé.
Un nom de client peut contenir une apostrophe, un guillemet, une balise. Il est traité comme du texte, jamais comme du code, y compris quand il vient de votre propre base.
La validation est côté serveur.
Le contrôle dans le navigateur sert le confort de l'utilisateur. Il ne sert à rien contre quelqu'un qui a désactivé le script — donc rien n'est admis sans être revérifié côté serveur.
Les secrets ne sont pas dans le code.
Mots de passe de base, clés d'envoi, jetons : hors du dépôt, hors du dossier web, hors des sauvegardes qui circulent.
On ne casse jamais l'existant pour livrer le neuf.
L'ancien système reste debout pendant la bascule. On coupe quand le nouveau a fait ses preuves, pas le jour de la mise en ligne.
Ce qui est affirmé est vérifié.
Un correctif n'est pas « fait » parce qu'il est écrit : il est fait quand il a été testé sur le système réel. Si un test échoue, c'est dit — avec la sortie du test.
La performance est une fonctionnalité.
Index sur ce qui filtre et ce qui trie, pas de requête dans une boucle, images au bon format, pages qui s'affichent avant qu'on ait le temps de s'impatienter.
L'outillage
Choisi, pas subi
Les outils changent tous les dix-huit mois ; les besoins de votre entreprise, non. Nous choisissons des techniques que nous saurons maintenir dans cinq ans, sur un hébergement ordinaire, sans dépendre d'une bibliothèque abandonnée par son auteur.
Serveur
- PHP 8.4
- MariaDB
- Requêtes préparées
- Sessions durcies
Le socle. Pas de cadre applicatif lourd imposé : ce qui est nécessaire, écrit proprement, et qui tourne sur un hébergement mutualisé comme sur un serveur dédié.
Interface
- HTML sémantique
- CSS moderne
- Alpine.js
- Tailwind
Une page doit s'afficher avant que le script n'ait chargé. Le navigateur sait déjà faire des fenêtres, des accordéons et des sélecteurs de date — autant s'en servir.
Mobile
- Flutter
- Dart 3
- Hors-ligne
- Terminaux industriels
Application native quand la caméra, le scanner ou le mode hors-ligne l'imposent. Application web installable quand ça n'apporterait rien de plus.
Données
- Schéma normalisé
- Migrations additives
- Sauvegardes
- Historique
Une base se conçoit avant d'être remplie. Les modifications de schéma sont additives et rejouables : on ne perd pas une colonne parce qu'une mise à jour s'est mal passée.
Ce que nous ne faisons pas
Franchise
- Un site de trois pages sans besoin de gestion derrière : d'autres le feront moins cher, et aussi bien.
- Reprendre un développement abandonné sans l'avoir lu entièrement — nous ne nous engageons pas sur du code que nous n'avons pas ouvert.
- Promettre une date que nous savons intenable pour emporter un dossier.
- Livrer sans reprise des données existantes : ressaisir trois ans d'historique à la main n'est pas une mise en service.
Parlons de votre situation
Même en désordre. C'est justement le désordre qui décrit le mieux le besoin.