L’entreprise face à l’IA: saisir l’anguille, ou pourquoi les démonstrations impressionnantes produisent encore si peu de transformations durables?
Dans l’article précédent, nous avons posé l’équation: l’intelligence artificielle confronte la Tunisie – ses entreprises, ses travailleurs et ses institutions – à plusieurs inconnues interdépendantes. Commençons par la première: l’entreprise.
L’IA y est souvent abordée comme un outil supplémentaire. On distribue quelques licences, on organise une formation au prompting, puis on attend que la productivité apparaisse.
Mais l’architecte d’intérieur pyromane du premier article ne se contente pas de déplacer les meubles. Il touche aux murs porteurs: process, responsabilités, données, logiciels et, parfois, modèles économiques.
Si l’on se fie à LinkedIn ou à la presse technologique, cette transformation serait déjà accomplie. Chaque semaine apporte son nouvel outil – ou la «version X» du précédent – promettant de décupler notre productivité, d’éliminer les tâches ingrates et, au passage, de rédiger un poème dans le style d’Abou El Kacem El Chebbi.
La réalité dans les entreprises est moins glamour. L’IA s’y comporte comme une anguille: tout le monde veut la saisir, peu parviennent réellement à la tenir.
L’anguille et la boucle POC
On trouve des licences distribuées sans stratégie, des comités IA sans mandat clair et surtout une multitude de pilotes, de prototypes et d’expérimentations qui ne débouchent sur rien de durable.
Plusieurs études récentes aboutissent, malgré leurs différences méthodologiques, au même constat: une minorité d’entreprises seulement parvient à dépasser l’expérimentation pour produire une valeur significative et mesurable.
Beaucoup sont entrées dans une boucle POC permanente.
Un Proof of Concept, ou POC, démontre qu’une technologie peut fonctionner en principe, dans un environnement protégé, avec des données sélectionnées et peu de conséquences en cas d’erreur.
Le problème commence lorsque le POC devient la forme permanente de l’adoption.
Nous disposons alors de prototypes impressionnants, mais de peu de systèmes auxquels une entreprise peut réellement confier ses opérations. Entre la démonstration et la production se dressent toujours les mêmes obstacles:
• la fiabilité des résultats;
• l’intégration aux logiciels existants;
• la protection des données;
• la maîtrise des coûts;
• la traçabilité des décisions;
• l’attribution des responsabilités;
• la mesure de la valeur créée.
Pourquoi cet écart persiste-t-il? En partie parce que les outils proposés aux entreprises sont issus d’un univers dont les priorités ne sont pas les leurs.
Une technologie née dans un autre univers
Pendant longtemps, l’informatique d’entreprise a été conçue pour structurer les données, standardiser les opérations et réduire les coûts. Comptabilité, bases de données, ERP et logiciels de gestion reposaient sur une promesse simple: la même entrée devait produire la même sortie. Appelons cet univers la Business-IT.
À partir des années 2010, le centre de gravité de l’innovation s’est déplacé vers le grand public. Smartphones, plateformes sociales et applications gratuites ont privilégié l’adoption rapide : on lance, on observe les usages, on corrige et on recommence. C’est le monde de la Social-IT.
Ces deux univers obéissent à des logiques différentes.
La Business-IT exige stabilité, contrôle et conformité. Elle considère la donnée comme un actif sensible, parfois même comme un passif juridique, qu’il faut protéger.
La Social-IT privilégie l’expérimentation, l’expérience utilisateur et la vitesse d’adoption. La donnée y devient une ressource économique, et l’utilisateur participe souvent au développement du produit par ses usages.
L’IA générative est largement issue de ce second univers. Elle est polyvalente, immédiatement accessible et conçue pour impressionner dès la première utilisation.
Mais l’entreprise lui demande de fonctionner selon les règles du premier: garantir un niveau de qualité, protéger les informations, expliquer les décisions et s’intégrer à des systèmes qui ne peuvent pas se permettre d’improviser.
Un chatbot peut se tromper dans une conversation sans provoquer de catastrophe. Un système comptable, médical, industriel ou bancaire ne bénéficie pas de la même indulgence.
Ce décalage explique une partie de la boucle POC. Ce qui fonctionne dans une démonstration créative ne satisfait pas nécessairement les exigences de la production.
L’entreprise ne peut pas bâtir son infrastructure critique sur le principe: ship it and see what happens.
Pour sortir de cette boucle, trois maximes peuvent servir de boussole.
Maxime 1: It’s always the process, stupid!
En 1992, le stratège James Carville résumait la priorité de la campagne de Bill Clinton par une formule devenue célèbre: It’s the economy, stupid!
Transposons-la à l’entreprise:
– Une stratégie IA qui ne part pas des process n’est pas une stratégie: c’est un catalogue d’outils.
La question économique reste toujours la même:
– Quel process voulons-nous améliorer, pourquoi et selon quelle mesure de réussite?
L’IA n’apporte pas automatiquement de l’intelligence
Comme les grandes technologies qui l’ont précédée, l’IA ne rend pas spontanément une organisation plus intelligente.
Elle peut rendre un process plus rapide, moins coûteux, plus régulier ou capable de traiter davantage de cas. Mais elle agit aussi comme un amplificateur: elle augmente les effets d’un bon process comme ceux d’un process défaillant.
Saupoudrer de la «poussière magique d’IA» sur une organisation mal conçue ne transforme pas ses dysfonctionnements en or. Cela permet parfois de produire les mêmes erreurs plus rapidement et à plus grande échelle.
La première étape ne consiste donc pas à choisir un modèle, mais à revenir au process:
1. Quel problème économique voulons-nous résoudre?
2. Quelles informations entrent dans le process?
3. Quelles transformations et décisions produit-il?
4. Où se trouvent les erreurs, les délais et les répétitions?
5. Quelles décisions exigent un jugement humain?
6. Quel résultat attendons-nous et comment sera-t-il mesuré?
Cette dernière question est essentielle. Une démonstration peut être «impressionnante». Un process doit être mesurable.
Deux expériences révélatrices
Bridgewater Associates, l’un des plus grands fonds d’investissement au monde, n’a pas demandé à une IA de «comprendre la finance». L’entreprise a défini une tâche beaucoup plus précise: classer des documents et des informations financières selon leur pertinence pour ses analystes.
Les modèles généralistes obtenaient initialement des résultats médiocres. Des instructions plus détaillées les ont améliorés, mais leurs performances ont fini par plafonner. Un modèle spécialisé, entraîné à partir des décisions des experts de Bridgewater, a ensuite produit environ 30 % d’erreurs en moins que le meilleur modèle généraliste testé, pour un coût d’utilisation nettement inférieur.
Une autre expérimentation chez Shopify a porté sur la gestion d’un catalogue de commerce électronique: catégorisation des produits, vérification des marques, extraction d’attributs et application de règles commerciales.
Là encore, le problème n’était pas formulé comme «utiliser l’IA dans l’e-commerce». Il avait été décomposé en une série de décisions vérifiables. Un modèle spécialisé de taille relativement modeste a obtenu un score de 87,3 %, contre 76,9 % pour la meilleure configuration généraliste testée, avec un coût annoncé nettement inférieur.
Ces résultats ne constituent pas une loi universelle. Ils montrent néanmoins ce qui distingue un projet opérationnel d’une démonstration: un process précis, un résultat mesurable et une boucle de correction.
Le succès n’est pas venu d’une IA magique ajoutée à l’organisation. Il est venu d’une meilleure définition du process.
Le gisement des process non structurés
L’IA ouvre néanmoins un nouveau territoire à l’optimisation des process: elle peut interpréter et transformer avec une grande souplesse des informations qui n’entrent pas naturellement dans les lignes et les colonnes de la Business-IT classique.
Pendant des décennies, les logiciels ont surtout exigé des données structurées: champs fixes, formulaires, catégories et règles explicites. Mais une grande partie de la vie des entreprises se déroule ailleurs – dans les courriels, les PDF, les présentations, les images, les contrats et les conversations avec les clients.
Puisque les systèmes traditionnels géraient mal ce désordre, l’humain – le Knowledge Worker – servait d’interface. Il lisait, interprétait, reformulait et saisissait l’information dans les logiciels de l’entreprise.
L’IA peut désormais prendre en charge une partie de ces opérations cognitives. Mais cette possibilité révèle aussi un problème:
– Les process fondés sur des données non structurées sont souvent eux-mêmes peu structurés.
«Traiter une réclamation complexe», «préparer une offre sur mesure» ou «analyser un dossier atypique» ne désignent pas toujours des process documentés. Ces tâches vivent souvent dans la tête des collaborateurs expérimentés, avec leurs raccourcis, leurs exceptions et leurs décisions intuitives.
Or, on ne peut pas automatiser correctement ce que l’on n’a pas commencé par comprendre.
L’IA ne remplace donc pas le travail de conception. Elle le rend même indispensable.
Maxime 2: My data, my AI
Une entreprise accumule une histoire: décisions, erreurs, méthodes, relations clients, pratiques métiers et compromis élaborés au fil des années.
Ce savoir institutionnel constitue une part importante de son avantage concurrentiel. Il vit dans les procédures et les bases documentaires, mais aussi dans les décisions quotidiennes des cadres, notamment dans ces cas limites où la règle formelle ne suffit plus.
Or, les modèles d’IA généralistes portent une œillère fondamentale:
– AI knows the internet. It doesn’t know your enterprise.
Ils peuvent connaître les principes généraux d’un secteur sans savoir pourquoi une entreprise accepte tel risque, refuse tel fournisseur ou traite tel client différemment. Ils connaissent la moyenne du monde, mais pas nécessairement l’exception qui fait votre métier.
L’enjeu n’est donc pas seulement de connecter un chatbot aux documents. Il consiste à transformer le savoir institutionnel en un actif explicite, gouverné et évaluable.
La deuxième maxime rejoint ici la première: les connaissances les plus précieuses sont souvent enfermées dans des process que personne n’a complètement documentés.
La «taxe du prompt»
Lorsqu’une entreprise utilise un modèle généraliste, elle doit lui fournir le contexte nécessaire: règles, critères, exemples, documents, exceptions et format attendu.
Elle paie alors ce que nous pourrions appeler une taxe du prompt.
Le système ne connaît pas durablement l’organisation. Il faut donc lui «réexpliquer» son métier à chaque utilisation – token après token, requête après requête.
Dans l’expérimentation consacrée au catalogue électronique, les instructions détaillées ont augmenté le coût de chaque appel de 28 à 55 %. Malgré cela, elles ne permettaient toujours pas de restituer toutes les décisions implicites des experts.
– L’intelligence louée se paie à chaque appel. L’intelligence possédée exige un investissement initial, mais peut ensuite être réutilisée à grande échelle.
C’est ce qu’illustrent les deux expériences précédentes. Leur avantage ne venait pas seulement du choix d’un autre modèle, mais de données spécifiques: classifications, corrections et jugements produits par les experts.
Le modèle spécialisé n’apprenait pas simplement des connaissances générales. Il apprenait la manière dont l’entreprise prenait une catégorie précise de décisions.
La qualité de ces données compte davantage que leur seule quantité. Chez Bridgewater, les classifications réalisées par des non-spécialistes se sont révélées peu utiles. Les experts ont dû intervenir sur les cas litigieux, là où leur jugement apportait réellement de la valeur.
Le véritable actif n’était donc pas le document brut. C’était la décision experte associée au document.
Des options, pas de recette unique
Cela ne signifie pas que chaque entreprise tunisienne doit immédiatement entraîner son propre modèle. Plusieurs trajectoires sont possibles.
Louer un modèle généraliste convient aux usages exploratoires, créatifs ou peu fréquents. Cette phase peut aussi servir à collecter les exemples, corrections et évaluations nécessaires pour mieux comprendre le besoin.
Adapter un modèle dans un environnement contrôlé permet d’exploiter les données de l’entreprise sans devoir construire toute l’infrastructure technique en interne. Cette voie offre davantage de spécialisation, au prix d’une dépendance partielle envers le prestataire choisi.
Construire ou entraîner un modèle spécialisé devient pertinent lorsque le volume est élevé, les résultats vérifiables, les données sensibles, les erreurs coûteuses ou la décision stratégiquement importante.
Dans la pratique, beaucoup d’architectures seront hybrides: un modèle généraliste pourra coordonner, expliquer ou traiter des situations nouvelles, tandis que des modèles spécialisés prendront en charge les décisions répétitives où le savoir de l’entreprise compte le plus.
Le principal obstacle ne sera pas nécessairement la puissance de calcul. Il restera souvent la qualité des données et le temps que les experts doivent consacrer à leur production.
“Intelligence Ownership”: Une question de souveraineté économique
Pour les entreprises tunisiennes, cet enjeu dépasse la protection abstraite des données.
Une organisation qui transmet continuellement son contexte à des services étrangers paie ses appels tout en externalisant une partie de son infrastructure cognitive. Elle ne perd pas nécessairement la propriété juridique de ses données, mais elle devient dépendante d’une plateforme pour les transformer en décisions.
Cette dépendance peut devenir une hémorragie silencieuse de savoir-faire.
Mais d’autres trajectoires sont possibles.
Si des modèles relativement modestes peuvent exceller sur des tâches spécialisées, l’avantage ne dépend plus seulement de la taille des datacenters. Il dépend aussi de la qualité du savoir métier.
Or, les entreprises tunisiennes disposent de connaissances précieuses dans la finance, l’industrie, la santé, le tourisme, les services administratifs et les relations avec les marchés européens, africains et arabes.
La question stratégique n’est donc pas seulement :
«Quel modèle devons-nous utiliser?»
Mais plutôt:
«Quelles décisions devons-nous continuer à posséder?»
Maxime 3: My process, my software
Pendant que le grand public débat de la capacité de l’IA à écrire des poèmes, une transformation plus silencieuse touche l’épine dorsale de la société numérique : le développement logiciel.
Le code offre aux modèles un environnement particulièrement favorable. Il peut être exécuté, testé et corrigé. Les outils actuels ne se contentent plus de compléter quelques lignes: ils peuvent produire des composants, modifier une application et construire des outils à partir d’un besoin formulé en langage naturel.
Cette évolution ne supprime ni l’architecture ni l’expertise. Elle peut cependant réduire le temps nécessaire pour transformer un besoin précisément défini en logiciel fonctionnel.
Du besoin au logiciel
J’en ai fait l’expérience en développant une application d’évaluation sur mesure pour mes étudiants.
Mon rôle n’était pas celui d’un codeur traditionnel, mais celui d’un chef de projet: définir les objectifs, décrire les flux, examiner les résultats et corriger la trajectoire. Des agents ont pris en charge une grande partie de la production technique. Une première version opérationnelle de l’application était disponible en quelques heures.
Cette expérience ne démontre pas que chacun peut désormais construire n’importe quel système. Elle montre que la frontière entre celui qui comprend le besoin et celui qui produit le logiciel devient plus poreuse.
Et cette évolution peut avoir une conséquence importante pour les entreprises.
Le renversement partiel du build versus buy
Pendant des décennies, le développement sur mesure était coûteux. Les entreprises achetaient donc des logiciels standardisés, puis forçaient leurs process à entrer dans les catégories prévues par l’éditeur.
L’outil ne s’adaptait pas à l’organisation; l’organisation s’adaptait à l’outil.
Une partie des mauvais process actuels provient de ce compromis. Les équipes ont construit leurs pratiques autour des limites d’un ERP, d’un CRM ou d’un logiciel acheté vingt ans plus tôt.
Lorsque le coût de production du code baisse, l’équation évolue. Une entreprise peut plus facilement:
• compléter un logiciel standard;
• automatiser une interface manquante;
• construire un outil interne ciblé;
• remplacer progressivement un composant trop rigide;
• développer une application adaptée à un process particulier.
D’où la troisième maxime:
– My process, my software: le logiciel peut de nouveau s’adapter au process, plutôt que l’inverse.
Le cas du catalogue électronique illustre indirectement cette évolution. L’équipe n’a pas seulement interrogé un chatbot. Elle a construit un environnement reproduisant le process réel : produits, règles, décisions et critères d’évaluation. Cet équivalent numérique permettait au système de s’exercer, de recevoir un score et de s’améliorer.
Autrement dit, il a d’abord fallu transformer le process en logiciel avant de pouvoir y intégrer efficacement l’intelligence artificielle.
Cette approche ouvre des possibilités aux entreprises tunisiennes, notamment lorsque les logiciels internationaux comprennent mal leurs contraintes, leurs langues, leurs pratiques commerciales ou leur environnement réglementaire.
Elle ne signifie pas que chaque PME doit reconstruire sa comptabilité dans un garage.
Le coût de production du code diminue, mais celui de la compréhension du problème, de l’intégration, de la sécurité, des tests et de la maintenance ne disparaît pas. Un logiciel produit plus rapidement peut également devenir une dette technique produite plus rapidement — encore un gain de productivité dont on se passerait volontiers.
L’entreprise obtient néanmoins davantage d’options. Le choix ne se limite plus à acheter une suite surdimensionnée ou à financer un long projet sur mesure. Des architectures plus modulaires deviennent possibles, combinant:
• des produits standard pour les fonctions communes;
• des interfaces développées sur mesure;
• des composants générés avec l’aide de l’IA;
• des modèles spécialisés pour certaines décisions;
• des mécanismes humains de supervision.
La séquence reste essentielle:
1. comprendre le problème;
2. redessiner le process;
3. définir les responsabilités et les garde-fous;
4. déterminer quelles données et décisions doivent rester maîtrisées;
5. choisir ce qui doit être acheté, adapté ou construit;
6. utiliser l’IA pour accélérer la mise en œuvre.
Commencer par générer le logiciel reviendrait, une fois encore, à automatiser un process que personne n’a pris le temps de penser.
Pour les entreprises tunisiennes: choisir plutôt que subir
Les trois maximes ne décrivent pas trois projets indépendants. Elles forment une même séquence:
– Comprendre le process. Posséder le savoir qui le différencie (Intelligence Ownership). Construire l’architecture qui permet de l’exécuter.
Le process indique où se trouve la valeur.
Les données et les décisions expertes constituent le savoir institutionnel.
Le logiciel transforme ce savoir en capacité opérationnelle.
L’IA n’est donc pas une couche magique que l’on ajoute à la fin. Elle devient un composant d’une organisation redessinée autour de ses décisions, de ses flux d’information et de ses responsabilités.
Un projet pertinent commence généralement par un problème économique clairement identifié, un résultat vérifiable, des données disponibles et une mesure de réussite définie avant l’expérimentation.
À l’inverse, un projet formulé comme «nous devons faire quelque chose avec l’IA» possède déjà toutes les qualités d’un futur POC abandonné.
Toutes les entreprises tunisiennes ne suivront pas la même trajectoire. Certaines utiliseront principalement des services généralistes. D’autres adapteront des modèles à leurs données. Quelques-unes pourront transformer leur expertise en solutions exportables.
L’enjeu n’est pas de tout construire localement ni de rejeter les plateformes internationales. Une souveraineté autarcique serait aussi coûteuse qu’illusoire.
Il s’agit plutôt de choisir consciemment:
• quelles technologies peuvent être louées;
• quelles données peuvent être confiées à un tiers;
• quelles décisions doivent rester maîtrisées;
• quelles compétences doivent être développées localement;
• quels process peuvent devenir des produits ou des services exportables.
L’IA peut renforcer la dépendance technologique de la Tunisie. Elle peut aussi aider ses entreprises à transformer leur savoir métier en logiciels, en modèles spécialisés et en nouveaux services.
Ces deux scénarios coexisteront probablement. La différence se jouera moins dans l’accès aux modèles — de plus en plus largement disponibles — que dans la capacité à comprendre les process, à organiser les connaissances et à passer de l’expérimentation à la production.
L’anguille ne devient pas moins glissante. Mais nous commençons à comprendre où la saisir.
La prochaine inconnue: que devient le travailleur du savoir?
Transformer les process, posséder les données et produire plus facilement des logiciels ne modifie pas seulement l’architecture de l’entreprise. Cela redistribue aussi le travail.
Lorsque la machine traite les cas simples, prépare l’analyse ou produit une première décision, les professionnels doivent davantage définir, vérifier, corriger et arbitrer.
Mais une difficulté apparaît: si l’IA accomplit les tâches par lesquelles les débutants apprenaient leur métier, comment former les experts de demain?
D’autres questions suivent. Comment reconnaître la contribution des salariés dont les décisions deviennent des données d’entraînement? Comment transmettre le savoir ? Comment organiser les carrières lorsque l’entreprise peut produire davantage avec moins de personnes?
Ce sera l’objet du prochain article : non plus ce que l’IA fait aux process de l’entreprise, mais ce que l’entreprise transformée fait au Knowledge Worker.
Car derrière chaque process rendu plus efficace subsiste une autre inconnue : la place que nous déciderons d’y laisser à l’humain.
Dr. Sami Bahri
Dr Sami Bahri est consultant senior en stratégie, technologie, marketing et gestion, doté d’une solide expertise dans les domaines de la transformation numérique et de l’intelligence artificielle (IA). Fort d’une formation en sciences naturelles (Dr. rer. nat.) et d’une expérience interculturelle (franco-germano-tunisienne), il accompagne depuis plus de 20 ans des entreprises internationales dans leurs projets de modernisation, d’optimisation des processus et d’innovation technologique.
En tant que consultant stratégique, manager de transition ou chef de projet, il aide les organisations à intégrer avec succès les technologies numériques – en particulier l’IA – afin de créer de la valeur ajoutée, de réduire les coûts et d’améliorer l’efficacité opérationnelle. Il intervient également dans le développement et la gestion du changement dans des contextes multiculturels.
Depuis 2025, il est également chargé de cours et coach en IA et transformation numérique à la German Business School de Tunis.
Auteur:
Cliquez ici pour lire l’article depuis sa source.