Ce que je prends en charge — et ce que je refuse.
Pas de catalogue de formules. Une liste de problèmes que j'ai déjà résolus, avec les décisions techniques que ça implique.
Six terrains
Applications web
Interface et back-office sur une même base de code. Rendu serveur quand le référencement compte, client quand l'interaction prime. Accessibilité et vitesse traitées comme des contraintes, pas comme des options.
typescript · php · rendu serveurApplications métier
Règles horaires, capacités, droits, arrondis, états intermédiaires. Le cœur est isolé du framework pour être testable — et remplaçable quand le fournisseur change d'avis.
domaine isolé · tests d'abordTemps réel & ingestion
Flux de capteurs, websockets, reprise après coupure, déduplication, agrégation. La question n'est pas « combien ça passe » mais « que se passe-t-il quand ça casse ».
websocket · files · idempotenceIA locale
Modèles qui tournent chez le client : transcription, recherche sémantique, extraction, génération contrôlée. Quantification, latence, coût par requête mesurés avant engagement.
ollama · vllm · quantisationInfrastructure
Hyperviseur, conteneurs, TLS, sauvegardes restaurées, supervision, alertes. Le serveur n'est pas un détail de fin de projet : il décide de l'architecture.
proxmox · docker · tunnel · alertesAudit technique
Performance, dette, sécurité de base, sauvegardes qui ne restaurent pas. Rapport écrit : ce qui casse, ce que ça coûte, dans quel ordre le réparer.
mesures · priorités · rapport écritComment un projet avance
1. Le problème, pas la solution. Une heure à comprendre la contrainte réelle. Souvent, la demande initiale n'est pas le vrai problème — et le dire fait gagner des semaines.
2. Décisions écrites. Une page d'architecture : ce qu'on choisit, ce qu'on écarte, et pourquoi. Relisible dans six mois, par quelqu'un d'autre.
3. Tranche verticale. Un chemin complet qui fonctionne — données, serveur, écran — avant d'élargir. Les mauvaises surprises arrivent tôt et coûtent peu.
4. Tests là où la règle est chère. Concurrence, capacité, argent, temps. Pas de couverture décorative à 100 % sur du code trivial.
5. Mise en production observable. Logs exploitables, métriques, alertes, procédure de reprise. Le critère : quelqu'un d'autre que moi peut diagnostiquer une panne à 3 h du matin.
6. Reprise possible. Dépôt propre, README qui explique le pourquoi, dépendances minimales. Le code appartient au client, pas à son auteur.
Ce que je ne prends pas
Projets sans périmètre écrit. Maintenance au forfait sur du code que je n'ai pas vu. Reprises sans accès au dépôt ni aux accès serveur. Délais annoncés avant d'avoir lu l'existant.
Et quand un problème ne relève pas de mes compétences, je le dis au premier échange — plutôt que d'apprendre à vos frais.