Page technique
Les vrais noms, pour qui veut vérifier
Le reste du site est écrit pour un dirigeant, sans jargon. Cette page-ci est écrite pour la personne qu'il consultera avant de signer : un prestataire informatique, un associé technique, un proche du métier. Vous y trouverez les noms d'outils, les versions et les procédures.
Les chiffres de cette page sont datés et recalculables. Ils ont été relevés le 21 août 2026. Si vous en constatez un qui a vieilli, signalez-le moi : je préfère une correction à une approximation.
Langages et bases de données
| Projet | Nature | Technologies |
|---|---|---|
| MissioFlow / CoolCare | Application web PWA | PHP 8.3, MySQL 8, Bootstrap 5, JavaScript natif. Service worker pour le mode hors connexion, génération PDF via Gotenberg (Chrome sans interface), API REST. |
| MissioFlow Mobile | Application mobile | React Native avec Expo, authentification par JWT contre l'API de l'application web. Livrée en AAB sur Google Play via EAS, avec mises à jour JavaScript par expo-updates et détection des montées de version natives. Version iOS en cours. |
| IliaCloud | Application web PWA | React 18 et Vite 5 côté client, Node.js 22 et Express 4 côté serveur, PostgreSQL 16. Terminal SSH dans le navigateur via xterm.js, WebSocket pour les métriques et les journaux en direct, JWT avec jeton de rafraîchissement, chiffrement AES-256-GCM des clés SSH, double authentification TOTP. |
| Sites vitrine | Sites statiques | Astro, servi par Nginx en conteneur. HTML, CSS et JavaScript natifs pour les sites les plus simples, sans dépendance de construction. |
| FailDaily | Réseau social multiplateforme | Angular 20 et Ionic 8 côté client, Node.js 20 et MySQL 8 côté serveur. Cible iOS, Android et navigateur. |
| RollerLogic | Jeu | Phaser, avec une interface en HTML et CSS. |
| Web Sentinel | Outil d'analyse | Python 3.8 et supérieur. Outil interne, non diffusé. |
Tests et analyse statique
Chiffres relevés sur la base de code de l'application métier, MissioFlow et CoolCare, au 21 août 2026,
avec phpunit --list-tests. Ils augmentent, donc ils vieillissent :
la commande exacte est documentée dans le dépôt pour pouvoir les recalculer.
Outils en place
-
PHPUnit pour les tests unitaires et d'intégration, avec
deux suites distinctes. Ils tournent en intégration continue sur chaque
demande de fusion et sur les branches
mainetproduction. -
PHPStan niveau 8 sur l'ensemble du répertoire
src. Avec une précision qui compte : un fichier de référence (phpstan-baseline.neon) fige les erreurs héritées constatées au moment de l'introduction de l'outil, soit environ 2 370. La chaîne d'intégration ne bloque donc pas sur ce passif, mais elle bloque sur toute nouvelle erreur. Une configuration sans référence (phpstan-strict.neon) sert à mesurer un module avant et après refonte. Annoncer « niveau 8 » sans mentionner cette référence serait trompeur. - SonarQube, auto-hébergé, branché sur l'application métier, sur le site du produit et sur les autres dépôts.
- Jest pour les parties JavaScript, Playwright pour les parcours de bout en bout et les captures de recette.
Infrastructure et déploiement
- Serveur dédié OVH, en France, administré en propre. Orchestration par Docker Swarm, routage et certificats TLS par Traefik, registre d'images privé.
- GitLab auto-hébergé avec intégration et déploiement continus. Le code n'est pas déposé chez un tiers.
- Deux environnements séparés pour le produit : une pile de démonstration alimentée par des données fictives et réinitialisée chaque nuit, et une pile de production avec des données réelles et une sauvegarde quotidienne conservée sept jours. Bases distinctes, aucun contact entre les deux.
-
Chaîne de livraison : développement sur
main, déploiement automatique sur la démonstration, validation visuelle, puis demande de fusion versproduction. La fusion déclenche le déploiement en production. -
Images étiquetées par empreinte de commit, jamais par une
étiquette mouvante du type
latest. Swarm détecte ainsi chaque construction, et un retour en arrière désigne une version précise plutôt qu'une supposition. - Migrations de base : sauvegarde systématique avant exécution, script de retour arrière fourni avec chaque migration, et vérification préalable de l'état attendu. Si l'état ne correspond pas, la migration ne démarre pas.
- Séparation site et application : le site de présentation d'un client et son application métier sont deux déploiements indépendants. Une panne de l'un ne peut pas atteindre l'autre.
Données et conformité
- Hébergement en France, sur une infrastructure que j'administre.
- Conformité RGPD implémentée dans le produit : effacement, durées de rétention, suppression en autonomie par le client, export des données.
- Documentation RGPD remise au client avec le projet, accord de sous-traitance et liste des sous-traitants publiés pour le produit.
- Réception formalisée : une liste de contrôle écrite, reprise ligne à ligne avec le client. Sur le projet CoolCare, 193 points, dont aucun classé non conforme.
Sur l'usage de l'IA
La question finit toujours par se poser, autant y répondre franchement plutôt que d'attendre qu'on la pose.
L'écriture du code est assistée par des outils d'IA. L'architecture, la revue et les tests sont humains. C'est précisément pour cette raison qu'il y a une analyse statique en niveau 8, un SonarQube branché en continu et plus de sept mille tests automatisés : ce qui compte n'est pas la manière dont une ligne a été écrite, c'est ce qui la vérifie avant qu'elle n'atteigne votre production.
Vous ne trouverez pas sur ce site de clause interdisant l'IA ni de balise censée l'écarter. Afficher l'un ou l'autre tout en travaillant avec serait intenable dès qu'on creuse.
Une question précise ?
Si vous conseillez quelqu'un sur un projet me concernant et qu'il vous manque un élément, écrivez-moi directement. Je réponds volontiers aux questions techniques, y compris celles qui cherchent la faille.