Ce que j’apporte

Travailler directement avec ceux à qui le problème appartient — personnel d’exploitation, fondateurs, les ingénieurs du client eux-mêmes — pour transformer un brief incomplet en un périmètre défini, avec un chiffrage et une définition du « terminé » convenue. Je l’ai fait des deux côtés : comme spécialiste interne des processus cartographiant des flux financiers et logistiques non documentés, et comme ingénieur extérieur cadrant des projets d’IA pour des PME qui n’en avaient jamais acheté.

Appui

recueil du besoin · cartographie des processus existant / cible · chiffrages · validation écrite avant construction · ateliers avec les parties prenantes

Démontré dans Cas 02 · Cas 04

Des systèmes d’IA qui doivent tourner dans une exploitation réelle : extraction documentaire avec une étape de relecture humaine avant tout enregistrement, assistants de support client avec structure des connaissances, intégration d’outils, gestion des sessions et escalade vers une personne, et des flux RPA sur des tâches financières et logistiques autrefois saisies à la main.

Appui

API OpenAI / Claude · RAG · réglage de la récupération · versionnage des prompts · tool calling · OCR (PyTesseract) · Power Automate · Datagrand RPA · Selenium · LangChain / LangGraph (évalués) · Ragas (preuve de concept) · n8n · Dify

Démontré dans Cas 02 · Cas 03

Relier des systèmes qui n’ont jamais été conçus pour être reliés — l’ERP hérité d’un client, des systèmes sources sans aucune API, des plateformes de commerce et de paiement tierces, des files de messages, et les étapes manuelles entre les deux. La décision récurrente est acheter ou construire, et j’ai été des deux côtés assez souvent pour savoir que la question intéressante est : quelle contrainte fait échouer la brique achetée ?

Appui

conception d’API REST · OpenAPI / Swagger · webhooks · OAuth 2.0 / JWT · RabbitMQ · Redis · PostgreSQL / MySQL · Shopify API · Stripe · PayPal · schémas d’intégration non intrusifs

Démontré dans Cas 01 · Cas 02

Assumer un système après sa mise en service. Des traitements longs qui reprennent où ils se sont arrêtés plutôt que de repartir de zéro. Des pannes qui apparaissent à une heure où une personne peut encore revenir au processus manuel. Un traitement par files pour qu’une requête lente ne bloque pas le client suivant. Des envois qu’un rafraîchissement de page ne peut pas déclencher deux fois. De la capacité inutilisée qui est rendue plutôt que retenue.

Appui

workers de file · traitement asynchrone · traitements à points de reprise · envoi idempotent · stratégie de cache · Docker · NGINX · CI/CD · déploiement et supervision cloud sur les plateformes de chaque projet

Démontré dans Cas 02 · Cas 05

J’ai mené la livraison et les décisions techniques, ⛔ pas des effectifs : l’arbitrage final d’architecture et de choix technologiques après avoir écouté l’équipe, la pratique de relecture de code sur laquelle une équipe s’aligne, et l’accompagnement des développeurs jusqu’à ce qui les bloque réellement — c’est-à-dire, d’expérience, presque toujours le contrat d’API et non le code.

Appui

leadership technique · pratique de relecture de code · accompagnement · planification de sprint et découpage · livraison en trois langues (anglais · mandarin · malais)

Démontré dans Cas 01 · Cas 05