50 questions que les dirigeants se posent sur l’IA

Face à l’IA, sortir l’épée contre son ordinateur n’a jamais accéléré une transformation digitale.

Hyperstack vient d’avoir trois ans. Sur cette période, j’ai accompagné plus de 150 entreprises dans leur développement et mené plusieurs dizaines d’audits et de roadmaps IA, de la PME au grand groupe.

Au fil de ces échanges, un constat revient presque systématiquement : tout le monde sait que l’IA va avoir un impact sur son entreprise, mais très peu de dirigeants savent réellement par où commencer. Les outils changent chaque semaine, les promesses sont énormes, et le sujet reste flou.

J’ai donc rassemblé ici les questions qui reviennent le plus souvent : par quoi commencer, quels fondamentaux mettre en place, comment choisir ses premiers projets, comment embarquer les équipes et comment éviter de dépenser de l’argent dans des démonstrations qui ne passent jamais en production.

Ce qu’il faut retenir

• Partez d’un problème concret, pas de la technologie. L’IA est un outil parmi d’autres : pour une tâche qui suit des règles précises, une automatisation classique est souvent plus fiable et plus rentable.
• Commencez petit : un département prêt, une équipe volontaire et un premier projet de 10 000 à 20 000 € qui livre un résultat visible en quelques semaines.
• Sur le périmètre choisi, les données doivent être propres et les outils connectables. Sinon, le premier projet consiste à construire ce socle.
• Un projet de transformation, c’est environ 50 % de conduite du changement : formation, relais internes et suivi après la livraison.
• Gardez une personne derrière les décisions métier et n’élargissez l’autonomie des agents IA que lorsque les résultats le justifient.

Comprendre par où commencer

1. Tout le monde parle d’IA. Est-ce que mon entreprise en a vraiment besoin ?

L’IA concernera toutes les entreprises. Il faut commencer dès maintenant à l’intégrer, en choisissant un premier cas d’usage concret. Elle a besoin de fondamentaux solides : des données structurées, des processus clairs et des outils qui communiquent. Chez Hyperstack, nous la considérons comme un outil parmi d’autres. Pour une tâche qui suit des règles précises, nous privilégions souvent une automatisation classique : son résultat est plus prévisible et elle peut offrir un meilleur retour sur investissement. Nous réservons l’IA aux étapes où elle apporte quelque chose, par exemple interpréter un document ou préparer une réponse. Le point de départ reste le problème à résoudre.

2. Je sais qu’il y a du potentiel, mais je ne sais pas par où commencer. Que faire ?

Je commencerais par préparer les équipes au changement. Pour faire remonter de bons cas d’usage, il faut aider les collaborateurs à prendre du recul sur leur métier. Demander « qu’est-ce que vous voulez faire avec l’IA ? » ne suffit pas. Il faut leur réserver du temps, proposer des grilles de questions et montrer des exemples : tâches répétitives, irritants, décisions récurrentes, fichiers manipulés. Ce travail fait émerger les vrais sujets. Ensuite, on les classe par impact, faisabilité et vitesse de mise en œuvre pour construire une roadmap et choisir les premiers projets. Vous pouvez aussi retrouver nos guides IA sur The Studio pour nourrir cette réflexion.

3. Comment savoir si mon entreprise est prête ?

Par définition, une entreprise n’est jamais « prête » dans sa globalité. La bonne question est : est-ce qu’un département est prêt à lancer un premier projet ? Je regarde trois choses : une donnée suffisamment propre, des outils métiers connectables (idéalement via API ou au moins via des exports fiables) et des personnes motivées. Avec un logiciel ancien, il faut demander directement à l’éditeur ce qui est accessible. Avec des SaaS récents, les API sont beaucoup plus fréquentes. Ensuite, choisissez un département où la friction technique est faible et l’impact potentiel élevé. Une équipe volontaire, avec des outils connectables et un cas d’usage concret, suffit pour commencer. Il n’y a aucune raison d’attendre que toute l’entreprise soit prête.

4. Faut-il commencer par former les équipes ou par lancer un projet ?

Je préfère faire avancer les deux ensemble. Une première formation permet aux équipes de comprendre ce qui est possible et de faire remonter des idées. Un projet concret leur donne ensuite l’occasion de pratiquer sur leur travail. Si vous formez sans donner d’outils ni de suite, les réflexes risquent de se perdre. Si vous déployez sans expliquer, l’outil risque d’être mal utilisé. Le bon enchaînement, pour moi, c’est une découverte des possibilités, une application sur un cas réel, puis un accompagnement pendant les premières semaines.

5. Faut-il obligatoirement faire un audit avant de commencer ?

Nous commençons toujours par un audit, surtout au-delà de 50 personnes. Son ampleur dépend du besoin, mais ce temps de diagnostic est essentiel. Il permet de faire remonter les cas d’usage, de comprendre les outils et les données, et de repérer où un premier projet aura le plus d’impact. Il sert aussi à identifier les personnes qui vont porter le changement et à lancer la discussion avec les équipes. C’est déjà de la conduite du changement. Chez Hyperstack, nos audits et roadmaps IA aboutissent à des projets priorisés, avec un périmètre, un budget et des responsables identifiés.

Choisir un premier projet

6. Quelle est la différence entre automatisation et IA ?

Une automatisation exécute des étapes définies à l’avance : quand tel événement se produit, appliquer telle règle, puis transmettre telle information. L’IA est utile quand une étape demande d’interpréter une entrée variable, comme un message libre ou un document hétérogène. Les deux se combinent très bien. Par exemple, l’IA peut proposer les informations à extraire d’une demande, tandis que des règles contrôlent les champs et organisent leur transmission. Je préfère réserver l’IA aux étapes qui en ont besoin plutôt que lui confier tout le processus.

7. Comment faire remonter les bonnes idées des équipes ?

Pendant une semaine, demandez à chacun de garder une feuille de papier ou une note sur son téléphone. À chaque tâche pénible ou répétitive, il note le problème précis, le temps passé et la fréquence : « j’ai recopié ces 12 lignes dans le CRM en 20 minutes », « j’ai cherché ce fichier pendant 15 minutes », « je refais ce reporting chaque lundi ». Mettre ces situations par écrit aide à prendre du recul. À la fin de la semaine, vous avez une base concrète pour repérer les tâches qui reviennent souvent, concernent plusieurs personnes et méritent d’être simplifiées ou automatisées.

8. Comment choisir entre dix cas d’usage intéressants ?

Pour un premier projet, je privilégie un petit périmètre, une intégration rapide et un résultat visible. Je préfère parfois accepter un ROI un peu inférieur si le projet peut être livré vite et montrer à l’organisation que ça fonctionne. Le premier projet a aussi une valeur politique : il crée de la confiance. Choisissez une équipe volontaire et surtout quelques promoteurs qui pourront raconter le résultat aux autres, oui, y compris à la machine à café. Méfiez-vous des programmes de transformation qui demandent un engagement de plus de 100 000 € sur un an avant d’avoir démontré leur valeur. Chez Hyperstack, nous commençons généralement par un audit court, puis une première mission de 10 000 à 15 000 € pour obtenir rapidement un résultat concret. Une fois ce premier succès obtenu, les projets suivants sont beaucoup plus faciles à lancer.

9. Pourquoi commencer petit si l’ambition est de transformer toute l’entreprise ?

Parce que la première étape doit nous apprendre quelque chose avant qu’on engage davantage d’argent et de temps. On découvre les contraintes des outils, la qualité des données et la manière dont les équipes réagissent. Un premier résultat visible donne aussi envie à d’autres personnes de participer. La technologie évolue aussi très vite : dans quelques mois, les outils et les possibilités auront peut-être changé. Un gros projet très long risque donc de reposer sur des choix dépassés avant même sa livraison. Cela n’empêche pas d’avoir une vision à long terme. On peut dessiner une trajectoire sur plusieurs mois tout en décidant de la suite après chaque étape. Je préfère cette progression à un gros engagement fondé sur des hypothèses encore fragiles.

10. Faut-il acheter un logiciel ou faire développer une solution sur mesure ?

Je garde les logiciels métiers qui font bien leur travail et qui peuvent communiquer avec les autres outils, notamment grâce à une API. Le sur-mesure vient souvent compléter ce qu’ils ne couvrent pas. Regardez les fichiers Excel ou Google Sheets créés à côté du CRM ou de l’ERP : ils révèlent souvent ces besoins. Une application dédiée, un portail ou une automatisation peut les prendre en charge et faire circuler les informations entre les logiciels. On construit ainsi autour du cœur métier. Si un outil est fermé, sans API ni export exploitable, son remplacement mérite en revanche d’être étudié.

Préparer les données et les outils

11. Nos données sont mal organisées : peut-on quand même commencer ?

Non, pas sur le périmètre que vous voulez automatiser. Il faut absolument que les données utilisées soient suffisamment propres, normalisées et compréhensibles, et que la stack soit lisible. Sinon, vous allez simplement automatiser le chaos ou demander à l’IA d’interpréter des informations contradictoires. Cela ne veut pas dire qu’il faut nettoyer toute l’entreprise avant de commencer. En revanche, sur le processus choisi, il faut savoir quelle donnée fait foi, où elle se trouve et comment elle circule. Si ce socle n’existe pas, le premier projet doit justement être de le construire.

12. Faut-il abandonner Excel pour faire de l’IA ?

Oui, j’essaierais de sortir d’Excel dès qu’il sert de base de données, de suivi de projet central ou de système métier. C’est là que commencent les problèmes de versions, de droits, de doublons et de données impossibles à connecter proprement. En revanche, Excel reste très bien pour analyser des données qui viennent d’un système structuré : faire un modèle financier, une analyse ponctuelle ou manipuler un export. Le problème n’est pas Excel en soi. C’est Excel utilisé comme infrastructure.

13. Faut-il remplacer notre ERP ou notre CRM ?

Pas si votre ERP ou votre CRM fait correctement son cœur de métier et qu’il est connectable. Mon premier réflexe est de vérifier les API, les exports et les possibilités d’intégration. S’il est ouvert, je préfère souvent le garder et construire autour : automatisations, interfaces, portail, data warehouse, etc. En revanche, si un logiciel bloque toute évolution parce qu’il est fermé, qu’il ne permet pas de récupérer les données ou qu’il impose trop de ressaisies, le remplacer peut devenir le vrai projet de transformation.

14. Peut-on connecter l’IA à tous nos logiciels ?

Il faut le vérifier logiciel par logiciel. Certains disposent d’interfaces documentées pour lire et modifier les données ; d’autres proposent des exports limités ou demandent des autorisations spécifiques. Et une connexion techniquement possible peut rester bloquée par la politique de sécurité du groupe. Avant de promettre quoi que ce soit, je veux savoir quelles informations on peut récupérer et quelles actions on peut déclencher. Des contournements existent parfois, mais leur fragilité et leur maintenance doivent aussi entrer dans le chiffrage.

15. Pourquoi une intégration apparemment simple prend-elle autant de temps ?

Parce que « connecter deux outils » cache souvent plusieurs questions. Où se trouve la bonne donnée ? Que signifie ce champ ? Qui peut nous donner accès ? Comment les erreurs sont-elles traitées ? Dans nos projets, la cartographie des sources et la compréhension des interfaces prennent une place importante. Construire rapidement une application ne supprime pas ce travail. C’est pour cela qu’un chiffrage sérieux doit regarder l’environnement réel du client, et pas seulement la fonctionnalité qu’il souhaite voir à l’écran.

Budget et valeur créée

16. Quel budget faut-il prévoir pour un premier projet ?

Pour un premier projet construit sur mesure, je vois le plus souvent des budgets entre 10 000 et 20 000 €. Quand le sujet est transverse ou encore flou, je préfère souvent commencer par un audit de l’ordre de 5 000 à 10 000 € avant d’engager le build. À l’échelle annuelle, pour une PME autour de 10 M€ de chiffre d’affaires, 1 % représente 100 000 €. Ce n’est pas une règle universelle, mais une enveloppe de cet ordre pour la transformation (data, automatisation, IA, outils métiers) ne me paraît pas aberrante si elle finance plusieurs projets priorisés et mesurés. Le mauvais réflexe serait de mettre 100 000 € sur un seul pari avant d’avoir démontré la valeur.

17. Quels coûts oublie-t-on dans le budget initial ?

Le développement initial est une partie du coût. Il faut prévoir les licences, la consommation des modèles, l’hébergement éventuel, les corrections et les évolutions après les premiers essais. J’ajouterais le temps des équipes : expliquer leur travail, tester et se former mobilise des personnes. Une solution livrée aura presque toujours besoin d’ajustements au contact du quotidien. Je préfère annoncer cette réalité dès le départ et prévoir une enveloppe adaptée, plutôt que laisser croire que tout s’arrête le jour où l’application est mise en ligne. Nous détaillons ces postes dans notre article sur les coûts cachés d’un agent IA après son lancement.

18. Comment calculer le retour sur investissement ?

Commencez par mesurer le fonctionnement actuel, même imparfaitement : combien de fois la tâche revient, combien de personnes la réalisent et combien de temps elle prend. Comparez ensuite avec le fonctionnement testé, en incluant les vérifications et les corrections. Les heures libérées donnent un premier indicateur ; il faut aussi regarder les délais, les erreurs ou la capacité de traitement. Mettez ces gains en face du coût complet du projet. Et distinguez une économie réellement obtenue d’une capacité supplémentaire que l’entreprise doit encore apprendre à utiliser.

19. Gagner vingt minutes par jour, est-ce vraiment créer de la valeur ?

Cela peut en créer, mais il faut dire laquelle. Vingt minutes libérées peuvent améliorer la réactivité, permettre de traiter davantage de demandes ou simplement rendre une journée moins pénible. Ce sont des bénéfices différents, qui ne se traduisent pas automatiquement par une baisse des dépenses. Je demanderais donc au responsable du service ce qu’il compte faire de cette capacité. Si l’équipe gagne du temps sur une tâche secondaire alors que le vrai blocage reste ailleurs, le résultat global sera limité. Le gain doit se lire à l’échelle du travail complet.

20. Comment éviter que la facture d’IA augmente avec les usages ?

Je ne chercherais pas forcément à empêcher la facture d’IA d’augmenter. Si elle augmente parce que les équipes utilisent davantage un outil qui leur fait réellement gagner du temps, c’est plutôt un bon problème. La vraie métrique est le rapport entre coût et valeur créée. En revanche, il ne faut pas utiliser un LLM pour tout. Dès qu’une étape est déterministe, une automatisation classique est souvent moins chère, plus rapide et plus fiable. L’objectif est donc d’augmenter l’usage utile de l’IA, tout en sortant de l’IA toutes les tâches qui peuvent être traitées autrement.

Passer du test à un usage réel

21. Qu’est-ce que je dois avoir concrètement à la fin du premier projet ?

Vous devez pouvoir décrire l’avant et l’après avec les utilisateurs concernés. Par exemple : auparavant, quelqu’un ressaisissait une demande ; maintenant, elle arrive préremplie et il la vérifie. Il faut préciser ce qui fonctionne, sur quels cas, ce qui reste manuel et ce qui appartient à une prochaine version. Un premier projet peut aussi livrer un socle de données ou une connexion indispensable. Dans ce cas, il faut l’annoncer comme tel et expliquer quel usage cette étape rendra possible, sans lui attribuer un gain qu’elle ne produit pas encore.

22. Combien de temps faut-il pour obtenir les premiers résultats ?

Sur un périmètre ciblé, je cherche un premier résultat en quelques semaines. Mais une première livraison, une équipe qui l’utilise et un gain mesuré sont trois étapes différentes. Il y a souvent une friction au départ : les gens apprennent, remontent des problèmes et adaptent leurs habitudes. Le calendrier dépend aussi des accès aux données et de leur disponibilité. Je préfère fixer un premier jalon observable, puis ajuster la suite, plutôt que promettre une transformation immédiate dès la mise en ligne.

23. Quelle différence entre une belle démonstration et un outil qui fonctionne ?

Une démonstration montre qu’un scénario peut fonctionner. Un outil utile doit traiter les dossiers réels, avec leurs différences, leurs pièces manquantes et les contraintes des utilisateurs. Nous avons rencontré un pilote où la taille des fichiers mettait en difficulté la plateforme choisie. Il a fallu revoir l’approche. C’est un bon rappel : la bonne question est de savoir si une personne peut accomplir son travail de bout en bout avec la solution. Cela se vérifie dans l’usage, pas seulement pendant une présentation.

24. Comment décider qu’un pilote a réussi ?

En définissant avant le test ce qui nous fera dire qu’il est utile. Quels dossiers doivent être traités ? Avec quel niveau de qualité ? Combien de temps restera-t-il à passer en vérification ? Qui doit l’utiliser ? À la fin, on confronte ces attentes aux résultats réels et au coût. Je regarde aussi si les utilisateurs reviennent spontanément vers l’outil. Un test qui fonctionne techniquement mais que personne ne veut utiliser doit nous conduire à revoir le besoin, l’interface ou l’accompagnement.

25. Quand faut-il arrêter un projet ?

J’arrête quand continuer ne promet plus un gain suffisant. Un exemple simple : l’outil fait gagner 10 minutes, mais il faut en passer 15 à vérifier et corriger son travail. Autre signal : après plusieurs essais avec les équipes, personne ne l’utilise. Avant de dépenser davantage, je demande ce qui bloque, si nous savons le corriger et ce que cette correction changera concrètement. Si le bénéfice reste trop faible ou incertain, on réduit le périmètre ou on arrête. L’argent déjà dépensé ne justifie pas, à lui seul, de poursuivre.

Faire adopter le changement

26. Pourquoi consacrer autant d’efforts à l’accompagnement qu’à la technique ?

Parce qu’une application modifie une façon de travailler. Il faut comprendre les habitudes, expliquer ce qui va changer, rassurer, former et traiter les difficultés rencontrées après la livraison. Je dis souvent qu’un projet de transformation, c’est 50 % de change management. C’est mon ordre de grandeur de terrain, pas une statistique. Si toute l’énergie part dans le développement, on peut livrer quelque chose de techniquement correct qui ne trouve pas sa place dans l’équipe. Le temps consacré aux personnes doit être prévu dès le départ.

27. Comment embarquer des équipes déjà débordées ?

En partant d’un problème qu’elles veulent réellement résoudre et en limitant l’effort demandé au début. Si la première promesse est de leur enlever un reporting pénible, il faut les associer à sa conception et montrer rapidement une version concrète. Il faut aussi reconnaître que tester prend du temps et le réserver dans leur planning. Une équipe déjà sous tension ne peut pas absorber indéfiniment un projet supplémentaire. Commencez avec quelques personnes, recueillez leurs retours et simplifiez l’usage avant d’élargir.

28. Comment identifier les champions internes ?

Cherchez des personnes qui connaissent bien leur métier, ont envie d’essayer et savent partager avec leurs collègues. Le plus à l’aise avec la technologie n’est pas forcément le meilleur relais. Un bon champion repère un problème concret, teste sérieusement et explique ce qui fonctionne comme ce qui bloque. Donnez-lui du temps et un interlocuteur pour faire remonter ses retours. Son rôle est d’aider l’équipe à progresser ; il ne doit pas devenir le support officieux de toute l’entreprise en plus de son travail.

29. Que faire quand les collaborateurs sont réticents ?

Demandez-leur ce qui les inquiète. Cela peut être la peur pour leur poste, mais aussi une mauvaise expérience passée ou la perspective de perdre du temps avec un nouvel outil. On ne répond pas de la même façon à ces situations. Être présent, tester sur un petit périmètre et montrer un bénéfice concret aide à construire la confiance. Et si la direction tient un discours contradictoire sur les objectifs, il faut traiter ce problème aussi. L’adoption dépend de la cohérence du projet, pas seulement de la bonne volonté des salariés.

30. Que dire aux salariés qui ont peur pour leur emploi ?

Il faut dire honnêtement que certaines tâches vont changer et que cela peut conduire à faire évoluer des postes. Je ne promettrais pas que rien ne bougera si ce n’est pas la réalité. En revanche, on peut expliquer par quoi on commence : les tâches répétitives ou pénibles, les reportings et les ressaisies. Puis construire les évolutions avec les personnes concernées. La direction doit assumer ce qu’elle cherche à obtenir. Un discours rassurant pendant le déploiement ne compensera pas des décisions managériales opaques ensuite.

Former et organiser

31. Une journée de formation à ChatGPT suffit-elle ?

Une journée permet de comprendre les bases, mais l’adoption se construit ensuite, sur les tâches réelles. Chez Hyperstack, nous proposons des ateliers Claude gratuits de deux heures : des démonstrations concrètes, puis du travail sur les cas et les blocages des participants. Pour une équipe, je compléterais cette première découverte par des ateliers métier et un suivi après les premiers essais. L’objectif est que chacun sache utiliser l’outil sur son travail et vérifier ce qu’il produit.

32. Faut-il former tout le monde de la même manière ?

Non. Tout le monde a besoin de comprendre les possibilités, les limites et les précautions d’usage, mais la suite doit dépendre du métier et du niveau. Un commercial, un responsable financier et une personne de la DSI ne viennent pas avec les mêmes besoins. Les managers doivent aussi apprendre à identifier les prochains projets et à juger leur intérêt. Je recommande de recueillir les attentes avant la formation, puis de travailler en petits groupes sur des exemples apportés par les participants. Cela évite une session trop simple pour certains et inaccessible pour d’autres.

33. Quel doit être le rôle du dirigeant ?

Le dirigeant doit clarifier ce que l’entreprise cherche à améliorer, arbitrer les priorités et donner du temps aux personnes impliquées. Il doit aussi porter un discours cohérent sur les conséquences du projet. Je lui conseillerais de tester lui-même quelques usages pour comprendre concrètement les possibilités et les limites, sans devenir l’expert technique de l’entreprise. Il peut déléguer le pilotage quotidien ; il doit rester disponible pour les décisions qui bloquent. Un projet présenté comme prioritaire mais jamais soutenu dans les arbitrages perd vite sa crédibilité.

34. Comment associer la DSI sans bloquer les initiatives des métiers ?

Associez la DSI dès le début. Les métiers expliquent ce qu’ils veulent améliorer ; la DSI vérifie comment le faire avec les outils et les règles de sécurité de l’entreprise. Mettez-vous d’accord sur ce qui peut être testé librement et ce qui demande une validation. Ce cadre simple évite de découvrir un blocage au moment de déployer.

35. Que faire si les salariés utilisent déjà des outils d’IA sans cadre commun ?

Le ShadowAI, ce sont les usages d’IA développés par les salariés sans cadre connu de l’entreprise. Commencez par comprendre quels outils ils utilisent, pour quelles tâches, avec quelles données et sur quels comptes. Ensuite, fournissez des outils autorisés et quelques règles compréhensibles. Ces usages révèlent souvent un vrai besoin : il faut s’en servir pour construire une solution qui aide les équipes. Nous détaillons cette démarche dans la partie consacrée à la cartographie du ShadowAI de notre guide sur le déploiement des agents IA.

Fiabilité et risques

36. Peut-on faire confiance aux réponses d’une IA ?

On peut lui confier du travail si l’on sait comment vérifier le résultat et quel niveau d’erreur est acceptable pour l’usage. Je commencerais par un ensemble de cas représentatifs, avec des réponses attendues et des exemples difficiles. Il faut regarder les erreurs, pas seulement la qualité de rédaction. Un texte très convaincant peut reposer sur la mauvaise pièce ou contenir une information inventée. Pour une tâche sensible, les sources et la possibilité de contrôle comptent autant que la fluidité de la réponse. La confiance se construit sur des essais, puis sur un suivi.

37. Jusqu’où peut-on laisser un agent agir seul ?

Je préfère commencer avec une autonomie limitée et l’élargir seulement lorsque les résultats le justifient. Un agent IA peut préparer une réponse ou proposer une modification avant qu’un humain ne la valide. Toutes les actions n’ont pas les mêmes conséquences : organiser un document et envoyer un engagement à un client appellent des contrôles différents. Il faut donc définir précisément ce que l’agent peut lire, proposer et exécuter. L’autonomie complète ne devrait pas être un objectif en soi ; le bon niveau est celui qui apporte de la valeur avec un risque maîtrisé.

38. Qui est responsable si l’IA fait une erreur ?

Dans nos projets, nous gardons une personne derrière les décisions métier et les envois d’emails. L’IA prépare une réponse ou une proposition ; un salarié la vérifie et la valide avant qu’elle produise un effet. Il doit avoir les informations et le temps nécessaires pour faire ce contrôle. Il faut aussi désigner qui traite les erreurs et corrige le processus. Cette organisation permet de savoir qui décide et qui intervient lorsqu’un problème survient. Elle ne signifie pas que toute la responsabilité juridique repose automatiquement sur le salarié qui valide.

39. Quelles données peut-on confier à un outil d’IA ?

Commencez par classer vos informations selon leur sensibilité et par identifier ce dont l’outil a réellement besoin. Un contenu public, un fichier client, des données de santé et une stratégie tarifaire ne demandent pas la même analyse. Avant de transmettre des informations confidentielles, vérifiez les conditions du service, les accès, la conservation et les usages possibles des données. La CNIL rappelle que les traitements de données personnelles par l’IA restent soumis au RGPD. Limitez les informations envoyées et faites valider les usages sensibles avant de les généraliser.

40. Faut-il héberger l’IA chez soi pour protéger ses données ?

Pas systématiquement. L’auto-hébergement peut répondre à un besoin de maîtrise, mais il implique aussi d’exploiter, de maintenir et de sécuriser le système. Je commencerais par préciser l’exigence : quelles données doivent rester où, et qui peut y accéder ? Il faut aussi distinguer l’application, les outils d’automatisation et le modèle. Héberger l’application chez soi ne garantit pas que le modèle qu’elle appelle traite les données au même endroit. Le choix doit porter sur le parcours complet de l’information, avec des moyens humains adaptés pour l’exploiter.

Choisir les technologies sans suivre les modes

41. Comment choisir entre les différents modèles d’IA ?

Choisissez-le en fonction des tâches qu’il devra réellement accomplir. Constituez quelques exemples représentatifs, comparez la qualité des réponses et regardez le coût, le délai et les contraintes de traitement des données. Un classement général ne répond pas à toutes ces questions. Pour une tâche simple, un modèle plus léger peut être suffisant ; pour une analyse difficile, le compromis peut être différent. Privilégiez une solution qui permet de faire évoluer ce choix plutôt qu’un projet dont toute la valeur repose sur le nom d’un modèle.

42. Faut-il absolument choisir un modèle français ou européen ?

Cela peut être une exigence légitime, mais il faut préciser ce qu’elle recouvre : localisation des traitements, confidentialité, dépendance stratégique ou règles propres à votre activité. Je suis plus critique lorsque la discussion s’arrête à la nationalité du fournisseur sans regarder les autres outils de l’entreprise ni les conditions du service. Utiliser déjà des outils américains n’annule pas les questions posées par un nouvel usage d’IA. Mon conseil est de comparer les options sur des exigences explicites, puis de tester leur efficacité sur votre besoin. La souveraineté mérite une analyse concrète.

43. Modèle ouvert ou propriétaire : qu’est-ce que cela change pour un dirigeant ?

Il faut regarder les droits et les possibilités concrètes plutôt que l’étiquette. Pouvez-vous exécuter le modèle dans votre environnement, le modifier, changer d’hébergeur et l’utiliser commercialement ? Avec quelles restrictions ? L’Open Source Initiative distingue notamment les poids accessibles d’un système d’IA pleinement open source. Et le fait qu’un modèle soit ouvert ne dit pas où votre prestataire l’exécute. Pour un dirigeant, le choix porte surtout sur le niveau de contrôle recherché et les compétences qu’il faudra mobiliser. Comparez aussi les coûts d’exploitation, pas seulement l’accès au modèle.

44. Comment éviter d’investir dans une technologie qui sera dépassée dans six mois ?

Il faut choisir des outils qui ont des chances de durer et prévoir qu’ils évolueront. C’est une partie du travail d’une agence : évaluer les solutions, vérifier qu’elles se connectent bien et anticiper leur maintenance. Chez Hyperstack, nous faisons ces choix avec vos usages et vos contraintes en tête, puis nous construisons et maintenons les intégrations. Cela limite le risque de devoir tout refaire à chaque changement d’outil.

45. Comment prendre en compte l’impact environnemental de l’IA ?

Je commencerais par éviter les traitements dont l’utilité n’est pas démontrée. Puis je regarderais si une automatisation classique suffit, si un modèle moins lourd donne un résultat acceptable et si l’on peut limiter les traitements répétés. Ce sont des pistes de sobriété, pas une mesure complète de l’impact environnemental. Pour annoncer un bilan chiffré, il faut des données et un périmètre explicites, incluant les traitements nécessaires et ce que l’usage remplace éventuellement. Je préfère reconnaître ce qu’on ne sait pas mesurer plutôt que publier un chiffre carbone sans méthode.

Choisir son accompagnement et tenir dans la durée

46. Faut-il recruter en interne ou travailler avec un prestataire ?

Les deux peuvent se compléter. Au lancement, un partenaire peut réunir rapidement les compétences nécessaires pour comprendre les besoins, connecter les outils et accompagner le changement. Lorsque les usages sont stabilisés, internaliser peut devenir pertinent pour piloter les évolutions et entretenir la connaissance métier. Je poserais donc deux questions : de quelles compétences avons-nous besoin maintenant, et lesquelles voulons-nous garder dans la durée ? Le choix du recrutement sera plus clair une fois ces besoins identifiés. Dans tous les cas, quelqu’un en interne doit rester responsable du projet.

47. Comment reconnaître un bon prestataire IA ?

Un bon prestataire n’essaie pas de vous vendre de l’IA à chaque problème. Il doit être capable de dire : « ici une automatisation suffit », « ici vos données ne sont pas prêtes » ou « ici il faut garder votre outil actuel ». Je regarderais aussi s’il sait travailler sur toute la chaîne : compréhension du métier, data, API et intégrations, build, formation et maintenance. Demandez-lui enfin comment il mesure le succès et ce qui se passe après la livraison. C’est précisément le positionnement que nous avons choisi chez Hyperstack : IA, automatisation, data et applications métiers, avec l’objectif de déployer quelque chose qui fonctionne dans votre stack existante, pas seulement une belle démonstration. Pour aller plus loin, voici comment choisir une agence IA.

48. Comment éviter de devenir dépendant de son prestataire ?

Il faut traiter ce sujet dès le départ : accès aux comptes, maîtrise des données, documentation, formation et conditions de reprise. Choisir des technologies connues peut faciliter le changement de prestataire, mais cela ne suffit pas si personne ne comprend ce qui a été construit. La documentation doit expliquer le fonctionnement et les raisons des choix. Je veux qu’un client puisse continuer avec nous parce qu’il y trouve de la valeur. Le fait qu’il soit techniquement incapable de partir ne devrait pas être la base de la relation.

49. Que faut-il prévoir après la livraison ?

Il faut prévoir qui reçoit les retours, qui corrige les problèmes et qui décide des évolutions. Les premiers usages révèlent toujours des cas qui n’étaient pas apparus pendant les tests. Sans suivi, les utilisateurs perdent confiance et reviennent vite à leurs anciennes habitudes. Je conseille donc une période d’accompagnement après la mise en production, puis un fonctionnement clair pour la maintenance. C’est aussi pour cela que chez Hyperstack, nous prévoyons souvent un run après le build : corrections, petites évolutions, suivi de l’usage et arbitrage des prochaines améliorations. Une application disponible mais délaissée n’a pas atteint son objectif.

50. Et la dernière question ?

J’ai menti, il n’y en avait que 49. Mais si vous êtes allé jusque-là, c’est que vous êtes déjà plus avancé que 95 % des gens.

Si l’une de ces questions se pose dans votre entreprise, parlons-en : réservez un échange avec l’équipe Hyperstack.