[{"content":"La pression est réelle : un comité de direction qui a lu trois articles, des éditeurs qui ajoutent « AI-powered » à leur plaquette, des équipes qui utilisent déjà des assistants sans le dire. Dans ce contexte, le réflexe est de lancer un POC pour montrer qu\u0026rsquo;on avance.\nC\u0026rsquo;est exactement l\u0026rsquo;erreur. Un POC réussi ne prouve rien d\u0026rsquo;autre que la faisabilité technique — la partie qui, aujourd\u0026rsquo;hui, échoue rarement. Ce qui échoue, c\u0026rsquo;est la mise en production, l\u0026rsquo;adoption et le modèle économique.\nVoici les quatre questions que je pose avant d\u0026rsquo;engager quoi que ce soit.\n1. Quelle décision ou quel geste métier change ? Pas « quel outil on déploie » : qu\u0026rsquo;est-ce que quelqu\u0026rsquo;un fera différemment lundi matin.\nSi la réponse est floue — « gagner du temps », « améliorer la qualité » — le projet n\u0026rsquo;a pas de cible et ne pourra pas être évalué. Si la réponse est nette — « l\u0026rsquo;assistante commerciale ne ressaisit plus les bons de commande reçus par mail » — on a un périmètre, un utilisateur, et un avant/après mesurable.\nFormulation utile : aujourd\u0026rsquo;hui X fait Y en Z minutes ; demain X fait Y en Z\u0026rsquo; minutes, ou ne le fait plus du tout.\n2. Qu\u0026rsquo;est-ce qui se passe quand le modèle se trompe ? Toute IA générative produit des sorties fausses avec assurance. La question n\u0026rsquo;est donc jamais « est-ce que ça peut se tromper » mais combien coûte une erreur, et qui la rattrape.\nTrois catégories, dans l\u0026rsquo;ordre de difficulté croissante :\nErreur visible et sans conséquence — un brouillon de mail mal tourné, un résumé approximatif. L\u0026rsquo;utilisateur corrige, le coût est nul. C\u0026rsquo;est là qu\u0026rsquo;il faut commencer. Erreur visible et coûteuse — un montant erroné dans une commande. Il faut un contrôle humain explicite dans le circuit, ce qui rogne le gain de temps annoncé. À chiffrer honnêtement. Erreur invisible — une donnée fausse injectée dans un système aval, une classification silencieusement biaisée. À éviter tant qu\u0026rsquo;on n\u0026rsquo;a pas de mécanisme de détection. C\u0026rsquo;est là que se logent les vrais incidents. Si un projet tombe dans la troisième catégorie et que personne ne sait comment détecter la dérive, ce n\u0026rsquo;est pas un projet : c\u0026rsquo;est une dette en construction.\n3. Où sont les données, et qui a le droit de les voir ? Deux sujets distincts qu\u0026rsquo;on confond souvent.\nLa localisation : quelles données sortent du SI, vers quel hébergement, sous quel contrat, avec quelle durée de conservation et quel usage pour l\u0026rsquo;entraînement. Un engagement de non-entraînement sur les données client doit être écrit dans le contrat, pas déduit d\u0026rsquo;une page marketing.\nLes habilitations : c\u0026rsquo;est le piège le plus fréquent. Un assistant branché sur une base documentaire hérite des droits du connecteur, pas de ceux de l\u0026rsquo;utilisateur. Résultat classique : n\u0026rsquo;importe qui interroge l\u0026rsquo;assistant et obtient le contenu de dossiers auxquels il n\u0026rsquo;a pas accès. Le RAG ne crée pas la fuite, il la rend interrogeable en langage naturel — et donc découvrable par accident.\nAvant tout déploiement : vérifier que la recherche respecte les ACL à l\u0026rsquo;exécution, utilisateur par utilisateur. Si l\u0026rsquo;éditeur ne peut pas le démontrer, la réponse est non.\n4. Combien ça coûte en régime établi ? Le coût d\u0026rsquo;un pilote n\u0026rsquo;a aucune valeur prédictive. Ce qu\u0026rsquo;il faut estimer :\nPoste À ne pas oublier Inférence Coût par usage × volume réel, pas volume pilote. Les usages qui marchent explosent. Intégration Connecteurs, SSO, journalisation, reprise de données. Souvent le premier poste. Maintien Un modèle est déprécié en 12 à 18 mois. Le prompt et les évaluations sont à refaire. Accompagnement Formation, support niveau 1, gestion des attentes. Systématiquement sous-estimé. Sortie Reversibilité : si l\u0026rsquo;éditeur triple ses tarifs, quel est le plan ? La ligne « maintien » est celle qui surprend le plus. Contrairement à un applicatif classique qui peut rester stable des années, une brique IA vieillit vite : les modèles changent, les API évoluent, les comportements dérivent. Il faut budgéter un entretien récurrent, pas un investissement one-shot.\nEt la technique ? Elle arrive après — et c\u0026rsquo;est volontaire. Le choix entre un éditeur intégré, une API, un modèle auto-hébergé ou une architecture RAG maison est une conséquence des quatre réponses précédentes, pas un point de départ.\nUn projet dont l\u0026rsquo;erreur est sans conséquence, sur des données non sensibles, avec un volume faible ? Un outil du marché suffit, on n\u0026rsquo;a rien à construire. Un projet sur des données réglementées, avec des habilitations fines et un volume élevé ? Là seulement la question de l\u0026rsquo;auto-hébergement devient pertinente — et le coût du choix précédent devient calculable.\nCommencer par la technique, c\u0026rsquo;est choisir une solution avant de connaître le problème. C\u0026rsquo;est aussi comme ça qu\u0026rsquo;on se retrouve avec un cluster GPU qui sert à résumer des comptes rendus de réunion.\n","permalink":"https://blog.quelen.net/posts/quatre-questions-avant-un-projet-ia/","summary":"\u003cp\u003eLa pression est réelle : un comité de direction qui a lu trois articles, des\néditeurs qui ajoutent « AI-powered » à leur plaquette, des équipes qui utilisent\ndéjà des assistants sans le dire. Dans ce contexte, le réflexe est de lancer un\nPOC pour montrer qu\u0026rsquo;on avance.\u003c/p\u003e","title":"Quatre questions avant de lancer un projet IA"},{"content":"Je m\u0026rsquo;appelle Bastien Quelen, je pilote un système d\u0026rsquo;information.\nCe blog n\u0026rsquo;est pas une veille technologique de plus. C\u0026rsquo;est un carnet de terrain : les décisions que je prends, celles que je regrette, et ce que l\u0026rsquo;IA change concrètement au métier de DSI — budget, sécurité, données, équipes, dette technique.\nTrois principes d\u0026rsquo;écriture :\nDu concret. Un article part d\u0026rsquo;une situation réelle, pas d\u0026rsquo;une tendance LinkedIn. Les coûts aussi. Un projet IA qui réussit techniquement et rate économiquement reste un échec. Le droit à l\u0026rsquo;erreur. Les retours d\u0026rsquo;expérience négatifs sont plus utiles que les success stories. Pour me joindre : bastien@quelen.net · flux RSS\n","permalink":"https://blog.quelen.net/about/","summary":"\u003cp\u003eJe m\u0026rsquo;appelle \u003cstrong\u003eBastien Quelen\u003c/strong\u003e, je pilote un système d\u0026rsquo;information.\u003c/p\u003e\n\u003cp\u003eCe blog n\u0026rsquo;est pas une veille technologique de plus. C\u0026rsquo;est un carnet de terrain :\nles décisions que je prends, celles que je regrette, et ce que l\u0026rsquo;IA change\nconcrètement au métier de DSI — budget, sécurité, données, équipes, dette technique.\u003c/p\u003e","title":"À propos"}]