Des produits que vous pouvez comprendre. Des systèmes sur lesquels nous pouvons construire.

Ce qu’il fallait résoudre

Un centre médical avec un nomenclateur de centaines de services tarifés avait besoin que chaque service soit une page propre, trouvable dans la recherche, avec prix et unité de mesure — pas un PDF avec la liste des prix. En plus, les prix et l’équipe changent, donc la clinique devait pouvoir les modifier elle-même, et les programmations devaient arriver à la réception immédiatement, pas dans une boîte e-mail.

Ce que nous avons construit

Next.js 14.2.35 (App Router) avec React 18, TypeScript et Tailwind. Chaque position du nomenclateur médical est devenue sa propre route statique : 521 fichiers `page.tsx` dans `src/app`, dont 481 sous `/servicii` — 184 physiothérapie, 122 services consultatifs, 61 examens médicaux périodiques, 27 gynécologie, 26 ozonothérapie, 23 forfaits de traitement, 18 médecine alternative, 12 diagnostic, le reste par sections. Le sitemap de production liste 890 adresses. Le site est bilingue ro/ru. Le contenu modifiable (médecins, forfaits, traitements, articles, paramètres, images) est stocké dans une base SQLite locale via `better-sqlite3`, avec journal WAL et clés étrangères actives, administrée depuis `/admin` via 20 routes API ; l’authentification utilise `jose` pour la session et `bcryptjs` pour le mot de passe, et le changement de mot de passe invalide les sessions existantes. Les formulaires de programmation et de contact sont validés avec `zod` + `react-hook-form` et envoient le message formaté directement dans Telegram, via Bot API. Il existe aussi un calculateur de prix sur `calculator`.

Ce qu’il fallait résoudre

Le menu d’un club change souvent, a des prix et des volumes qui doivent être exacts, et il est lu sur téléphone, dans le noir, par des personnes qui parlent trois langues. Un PDF scanné sur un code QR ne résout rien de tout cela : il n’est pas consultable, il n’est pas traduisible, il ne se met pas à jour sans réimprimer le code.

Ce que nous avons construit

Un menu numérique sans cadre de travail ni paquets : les sources réelles sont quatre fichiers JSON, et un générateur Python de 402 lignes en écrit un seul `index.html`. 119 produits dans 21 catégories, chacun avec prix, volume, composition et photo ; 119 courts textes de présentation, un par produit ; 119 ensembles de recommandations d’association (« avec quoi cela va »), que le visiteur voit sur chaque carte. Le menu a trois langues : le roumain sert de base, et le russe et l’anglais couvrent non seulement l’interface, mais aussi les catégories, les volumes, les compositions, les 82 étiquettes de goût et les 119 textes de présentation. Le panier, la liste de favoris et le partage de l’addition fonctionnent dans le navigateur, sans compte et sans serveur. Les polices sont hébergées sur le même domaine, pas chez Google. Avant chaque publication, un script de 233 lignes exécute 16 vérifications — qu’aucun traceur ne s’est glissé, qu’aucune requête n’est faite à un domaine tiers, que le JSON est valide et que chaque image existe, que le menu est complet dans les trois langues, que les prix baissent dans chaque catégorie et que les données structurées de la page sont valides. La publication se fait automatiquement depuis GitHub Actions lors de la fusion dans `main`, après que le workflow a fait une copie complète de la production et l’a conservée 30 jours.

Ce qu’il fallait résoudre

Une mairie de commune doit avoir un site web officiel conforme à la HG 728/2023 — avec des sections fixes (transparence décisionnelle, projets et décisions, annonces, documents, contacts, budget) — et doit pouvoir le mettre à jour elle-même, sans développeur à chaque annonce. Sans cela, l’information d’intérêt public reste sur papier ou dans un groupe Facebook.

Ce que nous avons construit

Application Laravel 12 sur PHP 8.2 avec MySQL 8, front-end Vite + Tailwind, empaquetée en deux conteneurs Docker (`japca_app` = nginx + PHP-FPM, `japca_db` = MySQL). L’architecture sépare intentionnellement deux types de contenu : celui éditorial qui change rarement (géographie, historique, institutions, contacts, budget) se trouve dans un seul fichier de configuration PHP de 1613 lignes que les modèles Blade lisent directement, tandis que celui qui change souvent (annonces, galerie photo, projets et décisions, documents, paramètres de transparence) se trouve dans MySQL et est édité depuis le panneau `/admin`. 40 modèles Blade, 32 routes, 10 migrations de base de données. L’authentification du panneau est limitée à 5 requêtes par minute depuis la même adresse — la sixième reçoit 429 — et chaque action d’administration entre dans une table d’audit. Les en-têtes de sécurité et le sitemap sont couverts par des tests automatiques qui s’exécutent en CI.

Ce qu’il fallait résoudre

La même chose que pour tout menu en code QR : il doit être rapide sur téléphone, correct au niveau des prix, lisible en trois langues et modifiable en cinq minutes quand la cuisine retire un plat. En plus, le restaurant n’a besoin d’aucun suivi des clients — et alors la vraie question est de savoir si quelqu’un construit vraiment un site qui ne collecte rien, ou s’il écrit seulement cela dans la politique de confidentialité.

Ce que nous avons construit

Un seul `index.html` généré par un script Python de 377 lignes à partir de fichiers JSON : 146 produits dans 31 catégories, 143 courts textes de présentation, plus les traductions en russe et en anglais pour les catégories, les noms, les volumes, les compositions, les étiquettes et les textes. Le panier, la liste de favoris et le partage de l’addition fonctionnent dans le navigateur. Le site est servi directement par Caddy 2, avec HTTPS automatique. Ce qui est intéressant, c’est que l’absence de pistage des utilisateurs n’est pas une promesse, mais une règle imposée par l’intégration continue : à chaque demande de fusion, la CI régénère `index.html` à partir des sources et refuse la PR si le résultat diffère du fichier du dépôt (donc la page publiée correspond toujours aux sources), puis exécute 14 vérifications — sans traceurs, sans aucune ressource chargée automatiquement depuis un domaine tiers, polices hébergées localement, aucun fichier de sauvegarde arrivé dans le dépôt, politique de confidentialité présente et liée depuis le pied de page, menu complet en trois langues, prix en ordre décroissant dans chaque catégorie, données structurées valides — et vérifie aussi que les en-têtes de sécurité n’ont pas disparu de la configuration du serveur et que l’adresse IP est masquée dans les journaux. Toutes les actions GitHub utilisées sont figées sur le hachage du commit, et le workflow démarre avec `permissions: {}`.

Ce qu’il fallait résoudre

non vérifié — nous n’avons pas les sources, donc je ne peux pas décrire le problème de fonctionnement sans l’inventer.

Ce que nous avons construit

Application React compilée avec Vite, servie statiquement par nginx, avec une version en russe sur `/ru/`. 181 adresses dans le sitemap de production. C’est tout ce qu’on peut affirmer de l’extérieur : les sources ne sont pas sur cette machine, donc je ne peux pas nommer les bibliothèques, la structure ou les intégrations.

Ce qu’il fallait résoudre

Un centre dentaire de district avait besoin d’une liste publique de services avec prix, d’un marquage clair de ceux couverts par l’assurance obligatoire, de l’équipe, du service d’urgence et de pages de transparence — modifiables par le personnel, pas par un programmeur. Quand nous avons pris le projet en charge, le panneau d’administration avait un problème grave : le mot de passe admin était comparé dans le navigateur et se retrouvait dans le paquet JavaScript public, et les requêtes d’écriture sur l’API pouvaient être faites par n’importe qui sur internet.

Ce que nous avons construit

Application React 18 + TypeScript sur Vite 6, avec routage `react-router-dom` — 22 écrans, des services et prix jusqu’aux urgences, à l’orthodontie, aux implants, à la pédodontie, à la transparence et au feedback. En arrière-plan, une API Express 4 lancée sous PM2 ; nginx sert les fichiers construits et ne relaie que `/api`. Les données publiques (services, équipe) sont dans des fichiers JSON lus à la fois par l’API et directement par le front-end. Ce que nous avons apporté, c’est la sécurisation : le mot de passe ne quitte plus le serveur — `POST `login` le vérifie là-bas et renvoie un jeton signé HMAC-SHA256 valable 12 heures, avec une limite de 8 tentatives par 15 minutes et par adresse IP et des comparaisons en temps constant ; les écritures sur `services` et `team` exigent désormais un jeton ; le secret de signature se génère seul dans un fichier avec droits 0600, conservé en dehors du dépôt ; l’API écoute seulement sur 127.0.0.1, donc nginx est le seul chemin public ; CORS est limité aux domaines propres, et le corps JSON est plafonné à 1 MB. Par-dessus cela, nous avons mis une CI qui compile, vérifie les types et refuse le paquet si elle y trouve un secret, plus Dependabot avec un rythme hebdomadaire pour npm.

Ce qu’il fallait résoudre

Une société de crédit a besoin de plus qu’un site web : la demande doit entrer en ligne, passer par un flux de décision, produire un contrat PDF, générer un échéancier de paiement et laisser une trace dans l’audit — et tout cela doit résister aux questions posées par un client qui demande le retour de ses données personnelles. La partie publique (calculateurs, articles, pages par type de crédit) doit en même temps attirer des personnes depuis la recherche.

Ce que nous avons construit

Deux moitiés dans le même dépôt. La partie publique est une application Vite + React Router compilée statiquement — 50 écrans, dont quatre calculateurs (crédit, éligibilité, refinancement, échéancier de paiement), des pages distinctes par type de crédit, un blog, des pages d’information précontractuelle et de conformité. Les routes roumaines restent sans préfixe, et les routes russes passent par `/ru/…`, avec des étiquettes canoniques et alternatives générées à partir de la langue de la route active. La partie métier est un backend Express modulaire en TypeScript, avec Prisma sur PostgreSQL : 16 modules — authentification, droits par rôle, flux des demandes, documents, paiements, notifications, tâches programmées, blog, SEO, GDPR, clients, leads, contact, calculateur, Google Ads, santé — et 18 tables dans le schéma Prisma, dont `Contract`, `Payment`, `AuditLog`, `GdprRequest`, `UploadedDocument`, `DailyKpiSnapshot` et `CronJobRun`. Il fonctionne sous PM2, avec des scripts séparés pour les migrations en production, les vérifications avant lancement, la génération des secrets, la copie de sauvegarde et la restauration de la base.

Ce qu’il fallait résoudre

Un service automobile est recherché dans des combinaisons très spécifiques — marque plus opération plus quartier (« réparation boîte automatique BMW Botanica »). Une seule page « Services » ne peut rien répondre à cela. Le problème technique est que le site est une application React à page unique, donc ce que voit le moteur de recherche est un `<div>` vide si rien de particulier n’est fait.

Ce que nous avons construit

Application React 19 + TypeScript sur Vite 6, avec React Router, mais pré-rendue à la compilation : chaque route sort du build comme un fichier HTML propre, donc le moteur de recherche reçoit du contenu, pas une page vide. La structure des adresses a été étendue par étapes vérifiables dans l’historique — de 206 pages indexables à 316 par l’ajout des combinaisons marque × catégorie de travail, des articles et des pages par secteur de Chișinău. Les routes ont des versions par langue, un sitemap d’images séparé, des images Open Graph et un paquet JavaScript découpé pour un chargement plus rapide. Le dernier commit a corrigé un détail qui ruine silencieusement l’indexation : l’adresse canonique, le `hreflang` et les adresses dans le sitemap émettent désormais tous la même forme avec barre finale.