Transformation IA : ce que nous avons appris
en multipliant par 3 notre production de code.

Ce document n'est pas un guide. C'est un compte rendu.

Nous sommes une agence de développement sur-mesure : onze personnes, à Paris, depuis 2021, plus de 300 projets livrés, toutes les compétences en interne. Début 2025, nous avons commencé à outiller notre propre production avec de l'IA. Nous nous sommes trompés plusieurs fois avant que ça tienne. Ensuite, nous avons déployé les mêmes méthodes chez nos clients, et nous nous sommes trompés à nouveau, autrement.

Ce que vous lisez, ce sont ces erreurs, les règles qu'on en a tirées, et les résultats obtenus une fois ces règles en place.

Trois constats qui reviennent partout

Vos équipes utilisent déjà l'IA, sans cadre. Des comptes personnels sur des outils grand public, ouverts dans un onglet à côté du CRM, avec des extraits de documents internes collés dedans. Ce n'est pas de l'indiscipline : l'outil aide, il est disponible tout de suite, et il n'existe pas d'alternative interne. On appelle ça le Shadow AI : l'usage d'outils IA hors du périmètre validé par la DSI. Le problème n'est pas l'usage. C'est que personne ne sait quelles données sortent, ni où elles vont.

Vos pilotes ne passent pas en production. Une preuve de concept convaincante, une démonstration réussie, un comité satisfait. Puis rien. Six mois plus tard, le sujet revient à l'ordre du jour sous un autre nom, avec un autre outil.

Vos formations n'ont rien changé. Une demi-journée, un intervenant, des exemples génériques. Trois semaines après, les pratiques sont identiques. Ce n'est pas un problème de formateur, c'est un problème de format : on ne change pas une habitude de travail avec une présentation.

Aucun de ces trois constats n'est dramatique. Ce sont les symptômes normaux d'une technologie qui arrive plus vite que les organisations. Ils ont un point commun : ce ne sont pas des problèmes d'outil.

Le contrat de lecture

Nous nous sommes imposé une règle en écrivant ce document : chaque affirmation devait renvoyer à quelque chose que nous avons réellement fait, chez nous ou chez un client, avec son contexte et son résultat. Tout ce qui aurait pu figurer tel quel dans le livre blanc de n'importe quel cabinet a été retiré.

Il n'y a donc ici aucune statistique de marché, aucune projection, aucun scénario. Les chiffres que vous lirez sont les nôtres et ceux de nos clients, avec leurs limites explicitées. Quand nous ne savons pas, nous le disons.

En contrepartie, ce document est partial. C'est le point de vue d'une équipe de onze personnes qui construit du logiciel sur mesure. Il ne prétend pas décrire un marché.

Comment il est organisé

D'abord notre propre transformation, échecs compris, puis la raison pour laquelle tant de pilotes meurent avant la production (chapitres 2 et 3). Ensuite la méthode que nous en avons tirée, en trois piliers, avec les cas clients qui la documentent, et la question de la souveraineté des données (chapitres 4 et 5). Enfin, par où commencer chez vous, et ce que nous ne vous promettons pas (chapitres 6 et 7).

Le point de départ

Début 2025, nous nous sommes équipés. Claude Code pour le développement, Claude Design pour la conception d'interfaces, des assistants connectés à notre propre base de code. L'installation a pris une après-midi. L'enthousiasme a duré une semaine.

Nous avons fait à ce moment-là exactement ce que nous voyons faire aujourd'hui dans la plupart des entreprises : nous avons distribué des outils à des gens, et nous avons attendu que la productivité monte. Nous n'avions ni parcours de formation, ni conventions d'usage, ni mesure. Nous avions des licences.

Les premiers gains ont été réels et immédiats, sur des tâches précises, chez certaines personnes. Puis la courbe s'est aplatie, et les problèmes ont commencé. Aucun n'était technique.

Voici les quatre qui nous ont coûté le plus cher, et ce qu'ils ont produit.

Échec n°1 : L'adoption n'est pas uniforme

Ce qui s'est passé. Les développeurs ont adopté en quelques semaines. Ils avaient un avantage : leur travail est déjà fait de texte structuré, versionné, testable. L'outil s'insère dans un flux qui existait.

Les designers et les chefs de projet, non. Beaucoup plus lentement que prévu, à l'échelle de plusieurs mois, pas de quelques semaines. Mêmes outils, même entreprise, même soutien de la direction. Des courbes d'adoption sans rapport les unes avec les autres.

Ce qu'on a compris. Nous avions traité « l'IA » comme un outil unique à déployer à une population unique. En réalité, l'outil ne rencontre pas les métiers de la même façon. Ce qui se vérifie vite s'adopte vite : un code passe ou ne passe pas les tests, la boucle est courte et objective. Ce qui se juge s'adopte lentement (une intention de design, un arbitrage produit, une relation client) parce que la valeur du travail n'est pas dans la production du livrable, mais dans le jugement porté sur lui.

Nous suivions aussi le mauvais indicateur : le taux d'équipement, pas le taux d'usage réel.

La règle qu'on en a tirée. On ne déploie pas « l'IA » à une entreprise. On la déploie métier par métier, avec des parcours différenciés, des cas d'usage propres à chaque métier et des critères de réussite propres à chacun. C'est de là qu'est né notre premier pilier : acculturer & former (chapitre 4.1).

Échec n°2 : Les peurs sont légitimes, et elles ne se dissipent pas seules

Ce qui s'est passé. Les questions ne sont pas venues en réunion. Elles sont venues en aparté, en fin de journée, formulées presque en s'excusant.

« Mon travail a donc disparu ? »

« Est-ce que vous allez me licencier ? »

« Est-ce qu'on ne réfléchit plus par nous-mêmes ? »

Nous avons d'abord répondu par de la pédagogie technique : les capacités, les limites, les bons usages. Ça n'a rien donné, parce que ce n'était pas la question posée. Nous avons sous-estimé, franchement, la part d'accompagnement humain que demande ce sujet.

Ce qu'on a compris. Une peur qu'on n'adresse pas ne disparaît pas. Elle devient silencieuse, et elle se traduit en non-usage. Personne ne s'oppose ouvertement à un outil validé par la direction : on l'utilise pour la démonstration, et pas dans son travail réel.

Ce qui a fini par répondre à la question n'a pas été un discours. Pendant cette période, l'équipe est passée de 8 à 11 personnes, avec un volume de projets en croissance d'environ 30 % par an. La productivité gagnée a financé la croissance, pas des départs. C'est un fait vérifiable par l'équipe elle-même, et c'est le seul argument qui ait porté.

La règle qu'on en a tirée. Un déploiement IA sans espace de parole et sans réponse honnête aux peurs produit du rejet silencieux, le plus coûteux, parce qu'il n'apparaît dans aucun tableau de bord. L'accompagnement humain se planifie comme le reste : des créneaux, des interlocuteurs nommés, et une position claire de la direction sur l'emploi, dite tôt et par écrit.

Échec n°3 : L'outil amplifie l'expert, il ne le remplace pas

Ce qui s'est passé. Un designer temporairement indisponible. Un délai à tenir. Un chef de projet qui prend Claude Design, produit un écran, le trouve correct. L'écran part en production. Le client n'est pas convaincu. Le design est repris ensuite par un designer.

Ce n'est pas un incident grave. C'est un incident significatif, parce que la mécanique est exactement celle que nous retrouvons ensuite chez nos clients : la disponibilité de l'outil fait croire à la disponibilité de la compétence.

Ce qu'on a compris. La leçon n'est pas que l'outil est faible. Entre les mains d'un designer, Claude Design est excellent : il accélère l'exploration, multiplie les variantes, raccourcit le trajet entre l'idée et l'écran. Entre les mains d'un non-designer, il produit des choses moyennes. Simplement plus vite qu'avant.

Ce qui manque au non-expert n'est pas la capacité à produire. C'est la capacité à juger ce qui a été produit : voir qu'une hiérarchie visuelle est fausse, qu'un espacement est incohérent, qu'un parcours va coincer à la troisième étape. L'outil ne fournit pas ce jugement. Il fournit une sortie plausible, ce qui est plus piégeux qu'une sortie visiblement mauvaise.

La règle qu'on en a tirée. L'IA hors de son métier sert à prototyper, jamais à livrer. Le brouillon d'un non-expert est un point de départ pour l'expert, pas un livrable. Formulé comme nous le disons en interne : ne jamais surestimer ses compétences à travers ses outils.

Échec n°4 : « Claude m'a dit de faire ça »

Ce qui s'est passé. La phrase est apparue en interne, sans mauvaise intention, au moment où quelque chose ne fonctionnait pas. Un choix technique discutable, une régression, une consigne mal comprise : l'explication passait par l'outil.

Elle nous a arrêtés net, pour une raison simple. Cette phrase n'existe pas face à un client. Personne ne veut l'entendre, et personne ne peut la dire. Un client qui a payé un livrable ne peut rien faire d'une responsabilité déplacée vers un logiciel.

Ce qu'on a compris. Le risque n'est pas que l'IA se trompe. Elle se trompe, c'est acquis, et ça se gère avec des tests et de la relecture. Le risque est qu'elle offre un endroit commode où poser la responsabilité. Une organisation qui accepte cette phrase en interne finit par produire des décisions que plus personne n'assume.

La règle qu'on en a tirée. L'ownership reste nominatif. Chaque livrable a un responsable humain, identifié, qui l'assume, IA ou pas. L'assistant n'est pas un co-auteur : c'est un outil de travail, au même titre qu'un compilateur ou un tableur. C'est de cette règle qu'est né le principe que nous appliquons aujourd'hui chez nos clients : l'IA prépare, vos équipes décident.

Ce qui a fini par tenir

Une fois ces quatre règles posées, la deuxième tentative a fonctionné. Rien de spectaculaire : du cadre.

• Des assistants connectés à notre base de code, à nos conventions et à nos composants, pas des assistants génériques. L'écart de qualité entre un assistant qui connaît le projet et un assistant qui le découvre est considérable.
• Des batteries de tests unitaires et end-to-end systématiques. C'est la contrepartie non négociable de la vitesse : produire plus de code plus vite n'a de sens que si la vérification suit. Le test n'est plus une bonne pratique, c'est le garde-fou.
• Une revue outillée. Chaque modification est relue par un humain, aidé d'analyses automatisées. Personne ne fusionne son propre travail sans relecture.
• Des conventions partagées et écrites, pour que l'équipe et les assistants produisent le même style et les mêmes structures.
• Des parcours par métier, avec des cas d'usage réels et un référent identifié pour chacun.

Le résultat, et sa nuance

Sur la production de code, nous allons environ trois fois plus vite qu'il y a dix-huit mois. À l'échelle d'un projet complet, le gain est de l'ordre de 50 %.

Cet écart est la donnée la plus importante de ce document.

Il s'explique simplement. La revue, la recette, la qualification du besoin et les allers-retours avec le client ne se compressent pas. Ces étapes sont majoritairement humaines et relationnelles : elles prennent le temps qu'elles prennent. Multiplier par trois la vitesse d'écriture du code ne multiplie pas par trois la vitesse de livraison d'un projet. Cela déplace le goulot d'étranglement ailleurs, et cela rend visible tout ce qui, dans un projet, n'était pas de la production.

Nous insistons parce que c'est précisément là que les promesses commerciales dérapent. Un prestataire qui vous annonce un facteur trois sur votre projet vous parle d'une étape, pas de votre projet.

Nous voyons passer beaucoup d'initiatives IA. Une bonne partie n'atteint jamais la production. Ce ne sont pas des échecs bruyants : le pilote fonctionne, la démonstration est réussie, tout le monde est satisfait, puis le sujet s'éteint sans que personne ne l'ait arrêté. Les causes se répètent.

Le périmètre est trop large. « Automatiser le service client. » « Mettre de l'IA dans les achats. » Un périmètre de cette taille n'a ni critère de succès, ni fin. Les cas d'usage qui aboutissent sont, à l'inverse, si étroits qu'ils paraissent décevants en comité : un seul type de document, un seul service, une seule étape d'un processus.

Personne ne porte le sujet. Un pilote sans sponsor doté d'un budget et d'un pouvoir d'arbitrage survit tant qu'il ne dérange rien. Dès qu'il faut modifier un processus, ouvrir un accès à un système existant ou prendre du temps à une équipe métier, il s'arrête. Ce n'est pas un problème technique, c'est un problème d'autorité.

Rien n'a été mesuré avant. Sans mesure de l'existant (combien de temps prend cette tâche aujourd'hui, combien de fois par jour, avec quel taux d'erreur, à quel coût), il devient impossible de démontrer un gain après. Le pilote se juge alors à l'impression qu'il laisse. Une impression ne finance pas une mise en production.

L'outil a été choisi avant le besoin. Une plateforme est acquise, parfois pour de bonnes raisons, puis on cherche quoi en faire. L'ordre inverse (un processus documenté, mesuré, dont on déduit l'outil) donne des projets plus petits, plus courts et beaucoup plus faciles à défendre.

Personne ne porte l'adoption. Le pilote est livré à des utilisateurs qui n'ont pas été associés à sa conception, qui n'ont pas été formés sur leurs propres cas, et qui n'ont aucun référent à qui poser une question le mardi matin. L'outil est disponible, il n'est pas utilisé, et l'échec est attribué à la technologie.

Ces cinq causes ont un point commun : aucune n'est technologique. Les modèles disponibles aujourd'hui sont largement suffisants pour la grande majorité des cas d'usage d'entreprise. Ce qui manque n'est pas de la capacité de calcul. C'est de la méthode.

C'est celle-ci que nous décrivons maintenant.

Notre méthode tient en trois piliers, dans cet ordre : acculturer & former, outiller & construire, autonomiser. L'ordre n'est pas décoratif. Chaque fois que nous avons commencé par le deuxième, parce que le cas d'usage était évident et le client pressé, nous avons livré un outil correct que peu de gens ont utilisé.

4.1 Acculturer & former

Ce pilier est né de nos deux premiers échecs. Les parcours segmentés par métier viennent de l'échec n°1 : nous avions déployé les mêmes outils à tout le monde et obtenu des courbes d'adoption sans rapport. L'espace donné aux questions difficiles, y compris « allez-vous me licencier ? », vient de l'échec n°2 : nous avons découvert que ces questions existaient parce qu'elles nous ont été posées, tard, et en privé. Ce n'est pas un chapitre de manuel. C'est notre rattrapage, transformé en méthode.

Segmenter par métier et par niveau. Un développeur, un commercial, un juriste et un opérationnel de production n'ont ni les mêmes tâches automatisables, ni les mêmes risques, ni le même point de départ. Nous construisons donc un tronc commun court (ce que fait réellement un modèle, ce qu'il ne fait pas, ce qui ne doit jamais sortir de l'entreprise), puis des ateliers séparés par métier. Le tronc commun dure une heure. Les ateliers métier durent, se répètent, et c'est là que tout se joue.

Partir des cas réels des équipes. Une formation générique montre ce que l'outil sait faire. Un atelier utile part de ce que les participants font le lundi matin. Nous demandons à chacun d'apporter une tâche récurrente et pénible de son propre travail. On la traite en séance, avec ses vraies données quand c'est possible, avec un échantillon anonymisé quand ça ne l'est pas. Ce qui sort de l'atelier n'est pas une compétence théorique : c'est un gain que la personne a constaté sur sa tâche, ce jour-là.

Prévoir l'espace pour les questions qui fâchent. Nous les posons nous-mêmes, à voix haute, en début de parcours, parce que nous savons qu'elles existent : est-ce que ce travail va disparaître, est-ce que la direction prépare des suppressions de postes, est-ce qu'on va perdre l'habitude de réfléchir. Une réponse honnête, même inconfortable, vaut mieux qu'un silence poli. Et cette réponse appartient à la direction de l'entreprise : ce n'est pas au prestataire de la donner à sa place.

Cadrer le Shadow AI plutôt que l'interdire. Une interdiction ne supprime pas l'usage, elle le rend invisible. Nous recommandons systématiquement l'inverse : recenser les usages existants sans les sanctionner, fournir un outil interne au moins aussi pratique que celui que les gens utilisent déjà, et écrire une règle courte (une page) sur ce qui peut sortir et ce qui ne sort jamais. Une règle qu'on lit en deux minutes est appliquée ; un document de vingt pages ne l'est pas.

La preuve. Notre propre montée en compétence est le cas le mieux documenté dont nous disposons. Nous connaissons les erreurs parce que nous les avons commises, et nous connaissons le coût de chacune. C'est la seule formation à l'IA que nous savons donner : celle que nous avons dû nous appliquer à nous-mêmes.

4.2 Outiller & construire

Passer de l'atelier au cas d'usage en production. Trois règles, toujours les mêmes.

Un périmètre borné. Un processus, un service, un type de document. Assez petit pour être en production en quelques semaines, assez répétitif pour que le gain soit visible. Un bon premier cas d'usage a l'air modeste : c'est précisément ce qui lui permet d'exister.

Une mesure avant et après. Combien de temps prend la tâche aujourd'hui, combien de fois par jour, avec quel taux d'erreur. On mesure avant de construire. Sans ce point de départ, il n'y a pas de démonstration possible, et le passage en production se négociera à l'intuition.

Une revue humaine sur les cas de doute. Le système traite ce dont il est sûr, et route le reste vers une personne, en indiquant le motif du doute. Ce n'est pas un aveu de faiblesse : c'est ce qui rend le déploiement acceptable en production, parce que le pire cas est connu à l'avance.

Imalize : de l'email à la commande ERP en moins d'une minute

Imalize est une société d'import-export.

Avant. Les commandes clients arrivaient par email. Formats hétérogènes, pièces jointes, texte libre, références écrites différemment d'un client à l'autre. Une personne lisait, interprétait, puis ressaisissait à la main dans l'ERP : références, quantités, conditions. Un travail sans valeur ajoutée, source d'erreurs, et qui devenait un goulot dès que le volume montait.

Ce que nous avons construit. Un workflow n8n auto-hébergé (n8n est un outil d'orchestration de tâches automatisées, installé sur une infrastructure que nous maîtrisons plutôt que chez un éditeur), branché sur la boîte email, en quatre étapes :

1. Réception et tri. Le workflow identifie les emails qui sont des commandes et écarte le reste.
2. Extraction. Un modèle Mistral lit l'email et ses pièces jointes, et en sort des données structurées : client, références, quantités, conditions.
3. Contrôle. Les données extraites sont confrontées au référentiel de l'entreprise. Référence inconnue, quantité inhabituelle, incohérence : chaque écart est signalé.
4. Création. Si tout est cohérent, la commande est créée automatiquement dans l'ERP. En cas de doute, elle ne l'est pas : elle part en revue humaine, accompagnée du motif exact du doute.

Le résultat. Moins d'une minute entre l'email et la commande dans l'ERP. Environ 90 % de ressaisie en moins.

Ce qu'il faut retenir de la mécanique. Rien dans ce dispositif ne décide à la place de l'entreprise. Le système prépare une commande ; l'ambiguïté remonte à un humain avec son contexte. C'est ce qui a rendu la mise en production possible : les équipes savaient exactement ce qui se passerait le jour où le système ne saurait pas.

Côté Neuf : industrialiser l'éditorial sans perdre le contrôle

Côté Neuf est un courtier en immobilier neuf.

L'enjeu. Un catalogue trop vaste et trop mouvant pour être couvert à la main. Chaque page manquante est une recherche perdue ; chaque page périmée est pire qu'une page absente.

Ce que nous avons construit. Une chaîne éditoriale automatisée sous n8n, qui a permis de produire plus de 3 000 pages, et surtout de les maintenir, avec un contrôle éditorial humain sur les gabarits, les règles de génération et les publications.

Le résultat. Les clics organiques ont été multipliés par 4 en six mois, et par 10 en douze mois.

Ce qu'il faut retenir. Le mot important n'est pas « produites », c'est « maintenues ». Générer trois mille pages en une fois est une opération de quelques jours, qui se dégrade en quelques mois. Ce qui produit le résultat au bout d'un an, c'est la mise à jour continue, et le contrôle éditorial, qui empêche la chaîne de publier n'importe quoi à grande échelle. Automatiser la production sans automatiser le contrôle revient à industrialiser ses propres erreurs.

4.3 Autonomiser

Le troisième pilier a un objectif explicite, que nous écrivons dans nos propositions : que vos équipes n'aient plus besoin de nous.

Des champions internes. Une personne par équipe, identifiée nommément, dont une part du temps est officiellement allouée au sujet. Pas un volontaire enthousiaste qui absorbera la charge en plus de son travail : un rôle reconnu, avec du temps. C'est le point le plus souvent négligé, et celui dont l'absence tue le plus de déploiements après le départ du prestataire.

De la documentation écrite pendant, pas après. Une documentation rédigée en fin de projet est écrite par des gens fatigués, pour des gens qui ne sont pas encore là. Nous documentons au fil de l'eau : ce que fait le système, ce qu'il ne fait pas, ce qu'il faut vérifier, et quoi faire quand ça casse.

Une passation datée. Une date, un périmètre, des personnes nommées des deux côtés. Après cette date, l'équipe conduit et nous répondons aux questions. La passation est un moment du projet, pas une intention de fin de projet.

Les preuves : Granit et Virgil. Deux clients qui gèrent aujourd'hui leur site sans nous, après documentation et passation. Ils ne nous appellent plus pour les opérations courantes : c'est exactement le critère que nous nous étions fixé. Un prestataire dont la valeur repose sur la dépendance de son client a un intérêt objectif à ce que le transfert de compétence échoue. Nous préférons être rappelés pour la suite qu'être retenus pour le quotidien.

Le principe qui clôt le chapitre. Ces trois piliers reposent sur une même ligne, que nous ne franchissons pas : l'IA prépare, vos équipes décident. Aucun des systèmes que nous mettons en production ne prend de décision de manière autonome. Ils lisent, extraient, classent, rédigent des propositions, signalent des anomalies. La décision reste à une personne, qui l'assume.

Le choix du modèle et de l'endroit où tournent vos données n'est pas un détail d'implémentation qu'on délègue à l'équipe technique. C'est une décision de gouvernance, au même titre que le choix d'un hébergeur pour votre ERP ou d'un lieu pour vos archives. Elle se prend au début, parce qu'elle est coûteuse à défaire.

Le modèle. Nous travaillons avec Mistral, éditeur français, et avec des modèles ouverts que nous pouvons héberger nous-mêmes. Le critère de choix n'est pas la performance brute : c'est ce que le cas d'usage exige réellement. Beaucoup de besoins d'entreprise (extraire des données d'un document, classer des demandes, préparer une réponse à partir d'une base documentaire) sont parfaitement traités par des modèles qui tournent sur une infrastructure maîtrisée. Prendre le modèle le plus puissant du marché pour lire des bons de commande revient à louer un semi-remorque pour aller chercher le pain, avec l'inconvénient supplémentaire que le semi-remorque est garé chez quelqu'un d'autre.

L'hébergement. OVH, Scaleway, ou vos propres serveurs. Données en France. Ce n'est pas une posture : c'est ce qui permet de répondre précisément, contrat en main, à la question « où sont nos données et qui peut y accéder ». Les entreprises qui ne peuvent pas répondre à cette question ne bloquent pas leurs projets pour des raisons techniques : elles les bloquent parce que le juridique ne peut pas signer.

RGPD dès la conception. Quelles données entrent dans le système, pourquoi, combien de temps elles y restent, qui y accède, comment on les supprime. Ces questions se traitent au cadrage, pas à la recette.

Deux engagements que nous prenons systématiquement. Les données d'un client ne servent jamais à entraîner un modèle. Et quand nous construisons un système de RAG (c'est-à-dire un système où le modèle répond à partir de vos propres documents plutôt que de sa mémoire d'entraînement), il y a citation systématique des sources : jamais de réponse sans source. Une réponse sans source n'est pas vérifiable ; une réponse vérifiable transforme l'outil en aide à la décision plutôt qu'en oracle.

Un cas en cours. Nous déployons actuellement une application pour l'AP-HP, avec un hébergement souverain, sur infrastructure certifiée HDS. Le déploiement est en cours ; nous en parlerons plus précisément quand il sera terminé, et si le client nous y autorise.

Une précision nécessaire. Nous ne délivrons aucune certification et nous ne promettons aucune conformité : la conformité s'apprécie avec votre direction juridique, votre DPO et votre régulateur. Notre rôle est de concevoir un système qui la rende possible, et de documenter les choix d'architecture assez précisément pour que vos équipes puissent en répondre.

• Santé : données de santé à caractère personnel : hébergement sur infrastructure certifiée HDS, traçabilité des accès. Voir la page Santé
• Assurance : cadre ACPR et exigences DORA sur la résilience opérationnelle et la maîtrise des prestataires critiques : réversibilité et documentation des dépendances dès la conception. Voir la page Assurance
• Secteur public : doctrine « Cloud au centre » : le choix de l'hébergement se justifie avant le choix de la technologie. Voir la page Secteur public
• Finance & conformité : KYC et LCB-FT : obligation de vigilance, piste d'audit reconstituable pas à pas. L'IA prépare le dossier et signale les écarts ; la décision reste à un analyste conformité nommé. Voir la page Finance & conformité

Nous proposons trois niveaux d'engagement, dans cet ordre. Chacun peut s'arrêter là.

Pré-cadrage : 48 heures, gratuit. Vous nous décrivez un processus ou une intention. Nous vous rendons un avis écrit : est-ce faisable, avec quelles données, quels sont les risques, et quel ordre de grandeur d'effort. C'est court, c'est écrit, et ça ne vous engage à rien. Dans une partie des cas, notre réponse est qu'il ne faut pas le faire, et nous expliquons pourquoi.

Cadrage et feuille de route : 2 à 4 semaines. Entretiens avec les équipes concernées, mesure de l'existant, identification de deux ou trois cas d'usage classés par rapport valeur/effort, architecture cible et choix d'hébergement, chiffrage. Livrable : une feuille de route présentable en comité de direction, et exécutable avec nous ou sans nous.

Programme de transformation : 2 à 3 mois. Formation segmentée par métier, un à deux pilotes menés jusqu'à la production, désignation et montée en compétence des champions internes, documentation et passation. C'est le format dans lequel les trois piliers du chapitre 4 s'appliquent en entier.

Il nous paraît plus utile de finir par les limites que par une promesse.

Nous ne vous promettons pas que l'IA prendra des décisions à la place de vos équipes. Aucun système que nous mettons en production ne décide seul. Ils préparent, proposent, signalent. La décision reste à une personne, qui l'assume. C'est une contrainte que nous avons choisie, et nous la maintenons même quand le cas d'usage semblerait pouvoir s'en passer.

Nous ne vous promettons pas qu'un projet complet ira trois fois plus vite. Notre production de code va environ trois fois plus vite ; un projet complet gagne de l'ordre de 50 %. La revue, la recette et les allers-retours avec vos équipes ne se compressent pas, et nous ne chiffrons pas comme s'ils le faisaient.

Nous ne vous promettons pas que tout mérite de l'IA. Certains processus doivent d'abord être simplifiés. D'autres relèvent d'une règle métier écrite en une journée. D'autres encore sont trop rares pour justifier quoi que ce soit. Quand c'est le cas, nous le disons, y compris pendant le pré-cadrage gratuit, y compris quand cela nous coûte une mission.

Nous ne vous promettons pas que vos équipes adopteront l'IA avec enthousiasme dès le premier jour ; les nôtres ne l'ont pas fait. L'adoption a été inégale selon les métiers, les peurs ont été réelles, et il a fallu y répondre autrement que par un discours.

Nous ne vous promettons pas de réussir sans sponsor interne. Une transformation portée uniquement par un prestataire s'arrête le jour où le prestataire s'en va. Il faut quelqu'un chez vous, avec un budget et un pouvoir d'arbitrage, qui porte le sujet. Sans cela, aucun prestataire ne réussira : nous pas plus qu'un autre.

Si ce document vous a paru juste, la suite raisonnable est modeste : prenez le pré-cadrage de 48 heures. Vous nous décrivez un processus, nous vous rendons un avis écrit. S'il n'y a rien à faire, nous vous le dirons, et cela vous aura coûté une conversation.

Scroll

www.agence-scroll.com · contact@agence-scroll.com

20 rue des Taillandiers, 75011 Paris

Estimer un projet : agence-scroll.com/estimer-mon-projet · Prendre rendez-vous : agence-scroll.com/prendre-rendez-vous