Parler du projet →
Menu
REP. 01 / OBJET

Des applications métierqui font vraiment le travail.

Développement d'applications web, d'API et de traitements de données adaptés à vos usages réels.

Le développement est mon métier depuis cinq ans, l'IA locale est la spécialité que j'y ai ajoutée. Vous n'avez pas besoin d'un projet d'IA pour me confier du développement.

PARLER DE MON PROJET →

REP. 02 / NOMENCLATURE

Du correctif ponctuel au système que vous gardez.

APPLICATIONS
API & INTÉGRATIONS
REPRISE
2.1 / APPLICATIONS

Application métier

Back-office, portail client, outil interne, tableau de bord, suivi d'activité. Un logiciel pensé pour l'usage réel, pas pour la démonstration, et que quelqu'un d'autre que moi peut reprendre.

PHP / Laravel · Node.js · TypeScript · PostgreSQL

2.2 / API & INTÉGRATIONS

API et intégrations

Relier vos outils entre eux, automatiser un flux qui se fait aujourd'hui à la main, construire l'API qui manque. Côté IA, les serveurs MCP exposent vos outils à un modèle sans réécrire l'intégration à chaque changement de modèle.

API REST · MCP · authentification par jeton · documentation

2.3 / REPRISE

Reprise d'existant

Votre application fonctionne mal, n'évolue plus, ou personne ne veut toucher au code. Je peux reprendre l'existant plutôt que tout reconstruire, quand c'est le choix le moins coûteux.

Laravel · PHP · reprise de code · dette technique

REP. 03 / REPRISE D'EXISTANT

Tout reconstruire n'est pas toujours la bonne réponse.

Beaucoup d'applications métier fonctionnent encore très bien, mais plus personne n'ose y toucher. Le développeur d'origine est parti, les dépendances ont vieilli, et chaque demande d'évolution devient un devis de refonte.

Reprendre un projet existant demande d'accepter du code que l'on n'a pas écrit, de le lire avant de le juger, et de commencer par le remettre sous contrôle plutôt que par le réécrire.

Je commence par un état des lieux, et je vous dis honnêtement si la reprise est moins coûteuse que la reconstruction. Parfois elle ne l'est pas.

REP. 04 / PRATIQUE

Rapprocher des sources qui ne se parlent pas.

Deux référentiels publics décrivent souvent la même réalité sans partager d'identifiant commun : des noms proches mais pas identiques, des adresses écrites différemment, des mises à jour qui ne se produisent pas au même rythme. Le travail consiste à faire correspondre ce qui doit l'être, signaler ce qui reste ambigu, et rejouer le rapprochement automatiquement à chaque nouvelle version des sources.

J'ai pratiqué cet exercice plusieurs années sur des référentiels publics du secteur médico-social, dont FINESS et SIRENE. Je connais ces données et leurs pièges de format, pas la réglementation du secteur elle-même : sur un projet médico-social, vous restez l'expert du métier, j'apporte le traitement des données.

La méthode elle-même n'est pas propre à un secteur : elle s'applique à tout référentiel public ou toute base métier qui doit être croisée avec une autre source sans clé fiable au départ.

REP. 05 / LIMITES

Ce que je ne vends pas compte aussi.

Kubernetes multi-sites et architectures conçues pour des plateformes nationales ou mondiales : hors de mon périmètre.

Tests d'intrusion, audit offensif et DevOps d'infrastructure à part entière : je ne les vends pas.

Je peux déployer avec Docker, Docker Compose ou Docker Swarm, mais je ne vends pas une offre d'exploitation d'infrastructure globale.

Côté IA, mon périmètre porte sur le texte, la recherche documentaire et les assistants métier. Pas de génération d'images, d'audio ou de vidéo.

REP. 06 / CONTACT

Un outil à construire, ou un existant à reprendre ?

Décrivez le problème actuel, même s'il est encore manuel. Je vous dirai si un développement spécifique est pertinent.

PARLER DE MON PROJET →