Aller au contenu principal

Blog

Des articles sur les sujets que je traite en mission : architecture logicielle, dette technique, intégration IA et visibilité dans les moteurs de réponse.

Peu d’articles, écrits à partir de ce que je constate en mission. Chacun commence par une réponse courte : si elle suffit, inutile de lire la suite.

  • Comment connecter un LLM aux données internes d’une entreprise sans tout réindexer

    Dans la majorité des cas, on ne réindexe rien. On donne au modèle le droit d’appeler les systèmes qui détiennent déjà la donnée (via la couche applicative existante, avec ses permissions) et on ne construit un index vectoriel que pour les contenus non structurés qu’aucune API ne sait interroger. La réindexation généralisée est une décision par défaut, rarement une décision motivée.

    Lire l’article
  • RAG ou fine-tuning : la question ne se pose presque jamais dans ce sens

    Le RAG donne au modèle des connaissances qu’il n’a pas : vos documents, vos données, votre contexte. Le fine-tuning modifie son comportement : format de sortie, ton, respect d’une nomenclature, tâche très répétitive. Un problème de connaissance ne se règle pas par du fine-tuning, et un problème de format ne se règle pas par du RAG. En pratique, plus de neuf projets sur dix relèvent du RAG ou d’une simple amélioration des instructions.

    Lire l’article
  • Ce que coûte réellement l’intégration d’une IA en PME : les postes qu’on oublie

    Le coût d’un projet d’intégration IA se répartit en trois blocs : la mise en état des données et du système d’information, souvent le plus lourd ; le développement de l’intégration elle-même ; et l’exploitation, qui comprend un coût variable par usage. Les appels au modèle représentent en général une part minoritaire du total. Un POC qui coûte quelques jours ne préjuge pas du coût de mise en production, qui est un projet logiciel à part entière.

    Lire l’article
  • Comment auditer une architecture logicielle avant une refonte

    Un audit d’architecture avant refonte se fait en cinq étapes : cartographier le système réel, recenser les points de douleur mesurés plutôt que ressentis, analyser où se concentre le coût du changement, formuler deux ou trois options chiffrées dont le maintien de l’existant, et produire un plan progressif. Il dure typiquement de deux à dix jours selon la taille du système, et sa conclusion est souvent qu’une refonte totale n’est pas nécessaire.

    Lire l’article
  • Dette technique : les trois signaux qui justifient un refactoring, et ceux qui n’en justifient aucun

    Un refactoring se justifie quand le code freine une évolution demandée, quand il provoque des incidents répétés, ou quand il bloque le recrutement et l’autonomie de l’équipe. Le code laid, ancien ou écrit autrement que ce qu’on ferait aujourd’hui ne justifie rien par lui-même : de la dette dans une zone stable que personne ne touche ne coûte rien. La question n’est pas « ce code est-il bon ? » mais « ce code nous coûte-t-il quelque chose de mesurable ? »

    Lire l’article
  • Ce que ChatGPT, Claude et Gemini voient réellement de votre site

    Les robots des assistants IA récupèrent une page et en lisent le texte ; la plupart n’exécutent pas le JavaScript, ou l’exécutent moins bien que Googlebot. Ce qui n’existe qu’après hydratation côté client peut donc leur être invisible. Le test décisif consiste à récupérer votre page sans exécuter de JavaScript et à regarder ce qui reste : si le titre, l’introduction, l’offre et la FAQ n’y sont pas, c’est exactement ce que voient ces robots.

    Lire l’article
  • Pourquoi un assistant IA ne cite jamais votre entreprise

    Un moteur de réponse cite une source quand il peut, à la fois, atteindre son contenu, en extraire une affirmation précise, identifier l’entité qui la porte, et la recouper ailleurs. Il suffit qu’un seul de ces quatre maillons manque pour ne jamais être cité. Dans la majorité des cas, le maillon manquant est l’extractibilité du contenu ou l’absence de traces externes cohérentes, pas la taille de l’entreprise.

    Lire l’article
  • MCP en production : exposer ses APIs à un agent sans ouvrir la porte

    MCP est un protocole qui standardise la façon dont un modèle découvre et appelle des outils. Il ne fournit ni authentification métier, ni autorisation, ni garde-fous : ces éléments restent votre responsabilité. En production, un serveur MCP doit exposer un petit nombre d’actions explicites, s’exécuter avec l’identité de l’utilisateur courant, passer par la couche applicative et non par la base, et journaliser chaque appel. Les opérations irréversibles demandent une validation humaine explicite.

    Lire l’article

Un cas concret à traiter ?

Un échange de 30 minutes suffit généralement à savoir si je suis le bon interlocuteur.

Me contacter