Au début d'un projet d'IA, les discussions tournent souvent autour du modèle : lequel choisir, que sait-il faire et comment l'intégrer ? Dès que le travail commence, on constate pourtant que les vrais obstacles sont ailleurs.
Il faut d'abord trouver un cas d'usage qui justifie l'investissement. Les données doivent ensuite être accessibles de façon licite et fiable, les systèmes d'identité et les applications métier doivent communiquer, et les critères de qualité doivent être définis avant la mise en service. Après le lancement vient l'exploitation. Une modification du prompt, du modèle, de l'index de recherche ou d'un service en amont peut suffire à changer le comportement du système. Google Cloud traite donc l'IA générative comme un cycle de vie logiciel continu, de la découverte à la surveillance en passant par l'expérimentation, l'évaluation et le déploiement, plutôt que comme l'installation ponctuelle d'un modèle.
Les compétences techniques en IA ne sont donc qu'une partie de ce que vous achetez. Un bon cabinet doit répondre aux questions ouvertes et permettre à votre équipe d'avancer seule une fois la mission terminée.
La partie réellement difficile
Sur les tâches adaptées, l'IA apporte des gains mesurables. Cela ne signifie pas qu'elle sera fiable sur la tâche suivante. Les mêmes travaux de recherche montrent clairement ces deux réalités.
Un document de travail du National Bureau of Economic Research portant sur des agents de service client a établi que l'accès à un assistant d'IA générative augmentait la productivité de près de 14% en moyenne. Une expérience de terrain de la Harvard Business School menée auprès de 758 consultants a montré que, sur des tâches situées à l'intérieur de la frontière de capacité du modèle, les utilisateurs d'IA accomplissaient 12,2% de tâches en plus et travaillaient 25,1% plus vite. Sur une tâche délibérément choisie au-delà de cette frontière, ces mêmes utilisateurs avaient en revanche 19% moins de chances d'aboutir à la bonne réponse.
Ces résultats ne permettent pas de conclure simplement que « l'IA fonctionne » ou qu'elle « ne fonctionne pas ». Ils montrent que la limite entre une réponse utile et une erreur formulée avec assurance est irrégulière. Elle traverse les tâches propres à chaque organisation, sans que personne sache exactement où elle se situe au départ. Une bonne mission rend cette limite visible ; une présentation générique sur la stratégie IA ne le fait pas.
On peut en tirer un principe simple pour choisir un partenaire :
Ne faites pas appel à un cabinet simplement parce que l'entreprise veut « faire de l'IA ». Faites-le lorsqu'il faut répondre à des questions concrètes sur la valeur, les données, l'architecture, l'intégration, la sécurité, la réglementation ou l'exploitation. À la fin, il doit rester plus que des présentations : votre équipe doit pouvoir continuer à travailler avec les résultats de la mission.
Ce que vous devez obtenir à chaque phase
Les schémas méthodologiques sont presque toujours convaincants. Une question est plus révélatrice : qu'obtiendrez-vous concrètement à la fin de chaque phase, et à qui cela appartiendra-t-il ? La stratégie, l'IA générative, la génération augmentée par recherche, les agents et le choix du modèle ne sont pas des disciplines séparées. Ils font partie du même cycle de vie logiciel. Le cadre de gestion des risques du NIST adopte la même approche et traite le risque IA comme un cycle continu de gouvernance, de cartographie, de mesure et de gestion, non comme un contrôle de conformité ponctuel.
| Phase | Ce que fait le cabinet | Ce que vous devez recevoir |
|---|---|---|
| Stratégie et identification des opportunités | Interroge les responsables métier et techniques ; examine les volumes, le coût des erreurs et les résultats mesurables ; distingue les problèmes d'IA des problèmes logiciels ordinaires | Portefeuille de cas d'usage priorisés, hypothèses de valeur, indicateurs de référence, matrice de faisabilité et de risque, et liste explicite des cas d'usage écartés avec les motifs |
| Analyse de processus | Cartographie le flux, les décisions, les exceptions et les transmissions avant toute automatisation | Cartes de processus actuel et cible, carte d'intégration, chemins d'exception, conception de la supervision humaine, limites de l'automatisation |
| Maturité des données | Établit quelles données existent, qui les détient, leur fraîcheur et leur fiabilité, et ce qui peut être utilisé licitement | Inventaire des données, matrice d'accès, constats de qualité, modèle de permissions, plan de comblement des lacunes et jeu d'évaluation représentatif |
| Architecture et intégration de modèles | Compare les modèles de fondation et le ML classique ; choisit les API, l'orchestration, la recherche, l'affinage ou les composants déterministes | Schémas d'architecture, registres de décisions, matrice d'évaluation des modèles, limites de sécurité, facteurs de coût, analyse de la dépendance fournisseur |
| Prototype ou MVP | Construit le plus petit flux complet capable de démontrer sa valeur dans des conditions réalistes | Application fonctionnelle, code source, configuration de déploiement, premières intégrations, premiers résultats d'évaluation, limites documentées |
| Ingénierie de production | Ajoute authentification, autorisation, gestion des secrets, journalisation, observabilité, replis, limitation de débit, auditabilité et escalade | Code de production, chaîne CI/CD, configuration IAM, modèle de menaces, suite de tests, documentation de gouvernance, procédures d'exploitation |
| Évaluation et mise en service | Teste la qualité des réponses, la recherche, la sécurité, le comportement adverse et les indicateurs métier face à des critères convenus à l'avance | Jeu d'évaluation versionné, résultats par cas d'usage, seuils de réussite, constats d'équipe rouge, décision de mise en service, registre des risques non résolus |
| Exploitation et optimisation | Surveille comportement, latence, coût, défaillances, retours et régressions à mesure que modèles et données évoluent | Tableaux de bord, alertes, processus d'incident, suite de régression, historique des versions, politique de mise à jour, transfert de compétences |
Si un prestataire ne peut pas décrire précisément la colonne de droite, la mission reste du conseil, même si l'offre parle de réalisation. Les recommandations de Google sont concrètes : jeux d'évaluation pour les cas courants et les cas limites, contrôle de version et CI/CD pour les prompts et les systèmes de recherche, journalisation de bout en bout et évaluation continue après la mise en service.
L'ingénierie des prompts n'en représente qu'une petite partie. Au quotidien, la réussite d'une application dépend tout autant de la recherche, de la logique applicative, des modèles, des API, des permissions et de l'expérience utilisateur.
Pourquoi le RAG et les agents sont plus exigeants
La génération augmentée par recherche, ou RAG, convient aux systèmes qui doivent travailler avec des informations internes ou fréquemment mises à jour. En pratique, l'application recherche d'abord les contenus pertinents dans les données de l'entreprise, puis les fournit au modèle comme contexte. Le principe paraît simple, mais sa mise en œuvre l'est beaucoup moins. Microsoft rappelle dans sa documentation Foundry que la qualité du résultat dépend fortement de la préparation des documents et du paramétrage de la recherche. Une réponse peut rester fausse malgré les sources fournies, et des droits d'accès mal configurés peuvent exposer des informations sensibles.
Une mission RAG doit donc livrer bien plus qu'une base vectorielle. Elle nécessite des processus fiables d'importation et de mise à jour, une stratégie cohérente de découpage et de métadonnées, une recherche qui respecte les autorisations, des sources vérifiables et des tests propres à la recherche. Un prestataire doit pouvoir expliquer comment il mesure la qualité de la recherche indépendamment de celle de la réponse. Une réponse vague révèle souvent un manque d'expérience en production. Les recherches supplémentaires, les embeddings et les jetons ajoutés au prompt augmentent aussi le temps de réponse et le coût de chaque requête.
Avec les agents, le niveau d'exigence augmente encore. Dès qu'un modèle peut appeler des API, modifier une base de données, envoyer des messages, créer des tickets ou agir sur des ressources cloud, il ne se contente plus de produire du texte : il agit. L'OWASP a publié en 2026 un Top 10 propre aux applications agentiques pour couvrir des risques tels que le détournement d'objectif, l'usage abusif des outils ou des identités, la compromission de la chaîne d'approvisionnement et l'exécution inattendue de code. L'injection de prompt reste elle aussi une menace. L'instruction malveillante peut être dissimulée dans un document traité par l'agent, sans avoir été saisie directement par un utilisateur.
Un projet d'agent exige donc des droits clairement limités pour chaque outil, des identités fondées sur le moindre privilège, une validation avant toute action lourde de conséquences, des plafonds de transaction, des journaux d'audit et des tests d'attaque. Il faut aussi pouvoir arrêter une action ou revenir en arrière. Si un prestataire propose d'emblée des droits très larges, considérez-le comme un signal d'alerte, pas comme un raccourci pratique.
Quand vous n'avez pas besoin de conseil
Tous les projets d'IA ne nécessitent pas un accompagnement externe. Une équipe interne peut généralement gérer seule un cas d'usage peu risqué lorsqu'un produit existant couvre déjà le besoin et qu'aucune intégration complexe n'est nécessaire. Les données doivent être accessibles, l'équipe technique doit maîtriser l'exploitation, la sécurité doit avoir évalué le service choisi et le métier doit pouvoir définir lui-même les critères de réussite.
Un accompagnement externe devient utile lorsque plusieurs équipes doivent résoudre ensemble des questions ouvertes. C'est souvent le cas avec plusieurs systèmes sources, des données sensibles, une architecture nouvelle, des contenus visibles par les clients, des décisions réglementées, des permissions complexes, des agents disposant de droits d'écriture ou le passage d'un prototype à une application fiable en production.
Sept questions permettent une première évaluation :
- Pouvez-vous définir un objectif mesurable, au-delà de la volonté « d'utiliser l'IA » ? Sinon, commencez par le processus, pas par le développement.
- Comprenez-vous le fonctionnement actuel et ses points faibles ? Sinon, cartographiez-le avant de chercher à l'automatiser.
- Disposez-vous de données représentatives, licites et suffisamment fiables ? Sinon, la base de données constitue le premier projet.
- Votre équipe compte-t-elle des ingénieurs capables d'intégrer et d'exploiter le système ? Sinon, vous avez besoin de réalisation, pas seulement de conseil.
- Pouvez-vous créer des cas de test et des critères d'acceptation ? Sinon, le partenaire doit transmettre cette compétence à votre équipe.
- Votre équipe de sécurité peut-elle évaluer les risques liés au RAG, à l'injection de prompt et aux agents ? Sinon, faites appel à l'expertise nécessaire.
- Qui prendra en charge le système après la mise en service ? Si la réponse reste floue, prévoyez un support managé ou un véritable transfert de compétences.
Parfois, l'IA n'est tout simplement pas la bonne réponse. Si le résultat attendu peut être décrit avec précision, un logiciel classique, un moteur de recherche, une automatisation de processus ou quelques règles claires seront souvent moins chers et plus fiables. Un modèle ne ferait alors qu'ajouter de l'incertitude. Le projet devrait attendre en l'absence d'objectif mesurable ou de données utilisables, si aucune erreur ne peut être tolérée sans contrôle efficace, ou si le processus change trop souvent pour être automatisé de façon responsable.
Automatiser
Un travail délimité et à fort volume, où une erreur est peu coûteuse à détecter et à annuler.
- Une référence mesurée existe déjà
- Des cas d'évaluation représentatifs peuvent être réunis
- Les erreurs apparaissent vite et sont réversibles
Assister
Un travail de jugement, où une personne reste comptable du résultat.
- L'IA rédige, une personne nommée décide
- L'effort de relecture est inférieur au travail sans aide
- Les actions conséquentes gardent un point de validation
Ne pas utiliser l'IA
Une tâche au résultat parfaitement prévisible ou dont les erreurs seraient irréversibles.
- Un logiciel déterministe produit déjà la réponse
- Aucun mécanisme de contrôle praticable n'existe
- Le processus est trop irrégulier pour être automatisé de façon responsable
Choisir le prestataire en fonction du besoin
Un classement ne permet pas de savoir quel prestataire conviendra à votre projet. Une entreprise industrielle suisse qui souhaite connecter un assistant à SAP et à sa documentation technique n'a pas besoin des mêmes compétences qu'une banque réglementée, un site de commerce en ligne ou une équipe qui déploie des agents d'infrastructure.
| Type de prestataire | Cas adaptés | Questions à poser |
|---|---|---|
| Cabinet de stratégie | Priorisation du portefeuille, modèle opérationnel, alignement de la direction | Qui mettra ensuite la stratégie en œuvre, et la faisabilité technique a-t-elle été vérifiée ? |
| Société de développement | Intégration de fonctions d'IA dans un ERP, un CRM, un SaaS ou une plateforme interne | L'équipe possède-t-elle aussi une expérience concrète des données et de l'évaluation ? |
| Cabinet spécialisé en IA | Recherche complexe, ML, évaluation de modèles, affinage, agents, sécurité IA | Peut-il construire et exploiter l'application de production autour ? |
| Intégrateur de systèmes | Projets étendus sur des plateformes établies et des systèmes anciens | Qui travaillera concrètement sur le projet, et combien de niveaux de coordination faudra-t-il gérer ? |
| Spécialiste indépendant | Investigation ciblée, revue d'architecture, travail d'évaluation, capacité temporaire | Que se passe-t-il si cette personne est indisponible ? Qui porte la sécurité et le support ? |
| Grand cabinet international | Projet multinational avec de forts enjeux réglementaires et de conduite du changement | Qui travaillera concrètement sur le projet, et quelles tâches seront sous-traitées ou confiées à des profils moins expérimentés ? |
Un bon partenaire de réalisation sait relier le processus métier et les données à l'architecture, au code, aux intégrations, à l'évaluation, à l'infrastructure et à la surveillance en production. Si sa responsabilité s'arrête à la stratégie et à l'architecture, il fournit du conseil, même si la présentation est excellente.
Ce que cela coûte et pourquoi l'écart est si large
Il n'existe pas de prix moyen vraiment utile pour le conseil en IA, car cette expression recouvre des prestations très différentes : deux semaines de découverte, un renfort d'ingénierie, un système RAG complet, du travail sur les données ou la sécurité, voire un programme de transformation international.
Les données de marchés publics fournissent au moins des chiffres réels. Sur l'accord-cadre G-Cloud du gouvernement britannique, un service de science des données cloud pour l'IA et le ML publie 240 à 940 GBP par jour. Une grille tarifaire spécialisée indique une analyste en protection des données à 500 GBP par jour, un ingénieur données IA à 850 GBP, un architecte IA principal à 1 100 GBP et un architecte IA en chef à 1 400 GBP, hors TVA et frais. Une autre offre d'IA générative du même accord-cadre annonce 300 à 1 400 GBP par jour. Ce sont des prix catalogue de fournisseurs sur un accord-cadre public britannique, non des moyennes indépendantes, non des tarifs du marché suisse, et non une estimation de ce que devrait coûter une mission donnée.
Ces chiffres montrent surtout que le périmètre et la composition de l'équipe influencent davantage le coût total qu'un tarif journalier isolé. Un architecte expérimenté qui règle les questions essentielles en deux semaines peut coûter moins cher qu'une équipe meilleur marché qui passe trois mois à construire le mauvais système. Pour des tâches courantes, ce même niveau d'expérience serait en revanche inutilement coûteux.
La plupart des missions suivent l'un de quatre modèles commerciaux. La régie convient à une phase de découverte ouverte et à un développement itératif, tandis que le forfait fonctionne pour des livrables clairement délimités. Les contrats récurrents couvrent la surveillance, l'optimisation et le support. Pour un projet d'IA, des jalons payants sont souvent le choix le plus raisonnable. Après la découverte, vous décidez si un MVP se justifie. Après le test du MVP, vous décidez d'investir ou non dans la production, puis dans l'exploitation continue. Le projet peut ainsi s'arrêter proprement lorsque les résultats ne justifient plus l'étape suivante.
Un contrat ne devrait jamais supposer que chaque prototype finira en production.
À la question « acheter ou construire ? », la réponse se situe le plus souvent entre les deux. Développer une solution sur mesure est rarement pertinent pour une tâche standard déjà bien couverte par un produit existant. Cela devient intéressant lorsque vos processus, vos données, l'expérience utilisateur ou vos contrôles font la différence. Beaucoup d'entreprises achètent donc le modèle ou la plateforme et développent elles-mêmes les couches de processus, d'intégration et de gouvernance. Créer son propre modèle de fondation est une tout autre entreprise : Google rappelle qu'il faut pour cela d'importants volumes de données, du matériel spécialisé et une expertise approfondie.
Combien de temps cela prend
Il n'existe pas non plus de durée moyenne vraiment pertinente. Les calendriers publiés par les fournisseurs donnent au moins un ordre de grandeur, à condition de les lire comme des offres et non comme des normes. Le service G-Cloud d'IBM prévoit une journée de cadrage initial, deux à quatre semaines d'ateliers de découverte, puis environ trois à quatre semaines pour développer un MVP avec le client. Un autre fournisseur prévoit une à deux semaines de préparation, quatre à six semaines de découverte itérative et encore quatre à six semaines pour rapprocher le prototype de la production.
Nos estimations sont volontairement plus larges. La découverte et l'évaluation de la maturité prennent généralement deux à six semaines, davantage si la responsabilité des données ou la qualification réglementaire reste floue. Un MVP ciblé demande souvent trois à huit semaines selon la préparation des données et les intégrations nécessaires. La mise en production fiable ajoute encore quatre à douze semaines, voire davantage, pour l'IAM, les tests de sécurité, l'intégration au système d'information, la résilience et la gouvernance. Le travail ne s'arrête pas au lancement, car les modèles, les fournisseurs, les données et les usages continuent d'évoluer.
Les missions publiques citées plus haut et les recommandations de Google sur la production correspondent à ces ordres de grandeur. Les applications réglementées, le ML sur mesure, les agents autonomes et l'infrastructure auto-hébergée peuvent demander beaucoup plus de temps.
- 012–6 semaines
Découverte et évaluation de la maturité
- Cas d'usage priorisés avec indicateurs de référence
- Cartographie du processus, des données et des droits
- Qualification réglementaire tranchée
- Liste explicite de ce qui ne sera pas construit
- 023–8 semaines
Un MVP ciblé
- Plus petit flux de bout en bout, intégrations réelles
- Jeu d'évaluation et seuils d'acceptation
- Limites documentées
- Décision de poursuite fondée sur des preuves
- 034–12+ semaines
Durcissement pour la production
- Authentification, autorisation, gestion des secrets
- Observabilité, replis et retour arrière
- Tests de sécurité et tests adverses
- CI/CD et procédures d'exploitation
- 04En continu
Exploiter et optimiser
- Surveillance de la qualité, de la latence, du coût et des défaillances
- Suite de régression à mesure que les modèles changent
- Historique des versions de prompts, modèles et recherche
- Transfert de compétences vers votre équipe
Cloud, privé ou auto-hébergé
Il n'existe pas de mode de déploiement idéal dans tous les cas. Le choix dépend du niveau de contrôle recherché et de la charge opérationnelle que votre équipe peut assumer.
| Approche | Ce que vous gagnez | Ce que vous assumez |
|---|---|---|
| Cloud managé ou API | Accès rapide à des modèles performants, peu d'infrastructure de service, accès rapide aux nouvelles capacités | Dépendance au fournisseur, revue contractuelle et de sous-traitance des données, coût d'usage variable, changements de modèle et d'API hors de votre contrôle |
| Privé managé ou hybride | Frontières réseau et données plus étroites tout en conservant des composants managés | Davantage de travail d'architecture et de plateforme, et les dépendances fournisseur ne disparaissent pas |
| Auto-hébergé à poids ouverts | Contrôle maximal sur le runtime, l'infrastructure et certains flux de données | Planification de capacité GPU, mise à l'échelle, correctifs, cycle de vie des modèles, observabilité, sécurité et astreinte deviennent les vôtres |
Un malentendu fréquent doit être dissipé dès le départ : l'auto-hébergement ne rend pas automatiquement un système conforme. Le droit suisse et européen de la protection des données s'intéresse à la manière dont les données personnelles sont traitées, pas seulement à l'endroit où le modèle s'exécute. Un système RAG dont les permissions sont défaillantes peut divulguer des informations confidentielles depuis votre propre centre de données aussi facilement que depuis le cloud.
Les coûts d'exploitation doivent être chiffrés avant de valider l'architecture. Selon la solution, ils comprennent l'inférence ou l'usage d'API, les embeddings, l'infrastructure de recherche ou vectorielle, le stockage, l'importation des données, les GPU, l'hébergement, la surveillance, les outils de sécurité, les campagnes d'évaluation, la maintenance et le support.
Comment évaluer un cabinet avant de signer
L'expérience concrète compte davantage que le vocabulaire employé. Demandez à chaque cabinet retenu d'expliquer comment un projet comparable est passé du problème initial à l'exploitation réelle. Un prototype soigné en dit peu si personne ne peut décrire la gestion des identités et des droits, l'évaluation, la réponse aux incidents ou la transmission à l'équipe cliente.
| Domaine | La question | Ce que contient une bonne réponse |
|---|---|---|
| Cas d'affaires | Comment déciderez-vous que ce cas d'usage ne doit pas utiliser l'IA ? | Indicateurs de référence, alternatives examinées, critères d'arrêt explicites |
| Données | De quoi avez-vous besoin avant le début du développement ? | Inventaire des sources, analyse d'accès et de qualité, évaluation de l'usage licite |
| Choix du modèle | Comment comparerez-vous les modèles ? | Évaluation propre à la tâche, pas des scores de classement |
| Recherche | Comment testez-vous la recherche indépendamment de la génération ? | Métriques de recherche, jeu de questions représentatif, citations, recherche tenant compte des droits |
| Agents | Que peut faire l'agent sans validation humaine ? | Moindre privilège, outils restreints, points de validation, auditabilité |
| Ingénierie | Qui porte l'intégration dans nos applications réelles ? | Expérience des API, tests, CI/CD, infrastructure as code, propriété du code |
| Évaluation | Quelles conditions doivent être remplies avant la production ? | Jeu de tests versionné, seuils d'acceptation, revue humaine, cas adverses |
| Sécurité | Comment traitez-vous l'injection de prompt et les fuites de données ? | Modèle de menaces, tests d'équipe rouge, contrôles de sortie, autorisations de recherche |
| Réglementation | Qui qualifie les obligations LPD, RGPD et règlement IA ? | Flux de données documentés, rôles de responsable et de sous-traitant, processus d'analyse d'impact |
| Exploitation | Que surveillez-vous après la mise en service ? | Qualité, latence, défaillances, usage, coût et télémétrie de sécurité |
| Résilience | Que se passe-t-il si le modèle ou la couche de recherche tombe ? | Délais d'attente, replis, dégradation maîtrisée, retour arrière |
| Propriété | Que nous remettrez-vous à la fin de la mission ? | Code source, définitions d'infrastructure, prompts, jeux d'évaluation, documentation |
Les signaux d'alerte reviennent d'un projet à l'autre : des chiffres de précision sans métrique définie, aucun jeu d'évaluation, la promesse d'un RAG sans hallucinations ou des droits illimités pour les agents. Soyez tout aussi prudent si le prestataire hésite à remettre le code et la configuration, ne peut montrer que des démonstrations, reste vague sur le support après le lancement ou recommande déjà un produit avant d'avoir compris les besoins.
Une bonne démonstration peut facilement masquer le travail restant. Une interface construite sur quelques documents soigneusement choisis paraît vite convaincante. En production s'ajoutent pourtant les contenus périmés, les droits différents selon les utilisateurs, les accès simultanés, les erreurs, la qualité variable des sources et les intégrations manquantes. Microsoft le souligne dans ses propres recommandations : la qualité de la recherche et le contrôle des accès restent des tâches d'ingénierie bien après le choix de l'architecture.
La Suisse et l'UE en 2026
Pour les entreprises suisses, le point de départ juridique est plus clair que le débat sur une future loi sur l'IA pourrait le laisser penser : le droit actuel de la protection des données s'applique déjà. La loi fédérale révisée sur la protection des données est en vigueur depuis le 1er septembre 2023. Selon le Préposé fédéral à la protection des données et à la transparence, elle couvre aussi les traitements de données personnelles assistés par IA. Les traitements limités à des informations factuelles sans lien avec une personne identifiable en sont généralement exclus.
En août 2026, la Suisse ne dispose pas encore d'une loi générale sur l'IA. Le Conseil fédéral souhaite mettre en œuvre la convention-cadre du Conseil de l'Europe sur l'IA, en mettant l'accent sur la transparence, la protection des données, la non-discrimination et la surveillance. Un projet de consultation est annoncé d'ici la fin de 2026. Les règles propres à chaque secteur continuent de s'appliquer en parallèle.
Les organisations entrant dans le champ du règlement européen sur l'IA font face à un calendrier plus détaillé. Le règlement est généralement applicable depuis le 2 août 2026. Les obligations relatives aux pratiques interdites et à la maîtrise de l'IA s'appliquent depuis février 2025, et celles de gouvernance et d'IA à usage général depuis août 2025. Après l'AI Omnibus, entré en vigueur le 27 juillet 2026, les cas d'usage à haut risque de l'annexe III disposent d'un délai jusqu'au 2 décembre 2027, et l'IA à haut risque intégrée aux produits réglementés de l'annexe I jusqu'au 2 août 2028.
Lorsque le RGPD s'applique, il ajoute un niveau d'exigence. L'article 22 encadre les décisions fondées exclusivement sur un traitement automatisé lorsqu'elles produisent des effets juridiques ou comparables. L'article 35 exige une analyse d'impact si le traitement risque fortement de porter atteinte aux droits des personnes. Dans son avis 28/2024, le Comité européen de la protection des données aborde directement les modèles d'IA. Le caractère anonyme d'un modèle entraîné sur des données personnelles et le recours à l'intérêt légitime comme base juridique doivent être évalués au cas par cas.
Dans le cadre d'un achat, les flux et les finalités des données doivent être documentés, tout comme les fournisseurs de modèles, les sous-traitants, les durées de conservation, les transferts internationaux, les droits d'accès, les décisions automatisées et l'intervention humaine. Un bon cabinet produit cette documentation au lieu de simplement aborder ces sujets pendant un atelier. Les conclusions juridiques restent du ressort de spécialistes du droit et de la protection des données.
Ce que montrent réellement les données
Dans les études de cas publiées, il faut distinguer les résultats communiqués par les entreprises des travaux indépendants.
UBS indique qu'un système d'IA générative prépare des synthèses d'évaluation dans la gestion de la performance, tandis que les responsables restent comptables de l'appréciation finale. Selon la banque, le système économise plus de 32 000 heures d'encadrement par an. UBS affirme également que son système d'approvisionnement « Front Door » a réduit de près de 40% le nombre de champs à saisir et accéléré certaines initiatives jusqu'à 60%. Siemens rapporte de son côté une baisse moyenne de 25% du temps consacré à la maintenance réactive lors des premiers pilotes de son Industrial Copilot. Ces chiffres viennent des entreprises elles-mêmes et ne permettent pas de prévoir le résultat d'un autre projet. Leur point commun est plus instructif : l'IA prend en charge une partie bien définie du processus, tandis qu'une personne reste responsable.
Les travaux du National Bureau of Economic Research et de Harvard cités plus haut sont indépendants, mais leurs résultats restent liés aux tâches étudiées. Les deux types de données conduisent néanmoins à la même approche : commencer sur un périmètre limité, mesurer la situation de départ, tester des cas représentatifs et maintenir un contrôle humain lorsque les erreurs ont des conséquences importantes. L'élargissement ne vient qu'après avoir confirmé la valeur dans l'usage réel.
Par où commencer
Lors du premier échange avec un prestataire, l'ordre des questions compte plus qu'une longue liste de noms. Commencez par le problème métier : comment le travail se déroule-t-il aujourd'hui, et que souhaitez-vous améliorer de façon mesurable ? Examinez ensuite les données et le risque réglementaire. Ce n'est qu'à ce moment-là qu'il devient pertinent de comparer une solution d'IA à une alternative classique. Construisez la plus petite version couvrant l'ensemble du processus et testez-la sur des cas convenus à l'avance. Elle ne devrait passer en production que si elle réussit ces tests. La surveillance doit ensuite se poursuivre, car les conditions ne seront plus exactement les mêmes six mois après le lancement.
C'est moins spectaculaire que de promettre un agent pour chaque processus. C'est aussi de cette manière que l'on construit des systèmes fiables.
Chez Alpine Edge, nous ne commençons pas par vendre une transformation globale par l'IA. Nous déterminons d'abord avec vous si un cas d'usage justifie l'investissement. Si c'est le cas, nous l'accompagnons de la découverte à une production fiable, en passant par l'architecture et l'intégration. Une phase de découverte ciblée ou une évaluation technique constitue généralement un meilleur premier mandat qu'un engagement immédiat sur un vaste programme.
D'où viennent ces chiffres
- Commission européenne, cadre réglementaire pour l'IA. Dates d'application du règlement IA, modifications de l'Omnibus 2026 incluses.
- Commission européenne, entrée en vigueur de l'AI Omnibus. Confirme le 27 juillet 2026.
- Chancellerie fédérale suisse, réglementation de l'IA. État des travaux et consultation prévue.
- PFPDT, IA et protection des données. Sur l'applicabilité de la LPD.
- PFPDT, l'IA au quotidien. Sur les données personnelles dans les traitements par IA.
- EUR-Lex, RGPD. Texte officiel, articles 22 et 35 inclus.
- Comité européen de la protection des données, avis 28/2024. Modèles d'IA et principes du RGPD.
- NIST, cadre de gestion des risques liés à l'IA.
- NIST, guide pratique du cadre. Gouverner, cartographier, mesurer et gérer.
- Microsoft, génération augmentée par recherche et index. Azure AI Foundry : conception, sécurité, limites et coûts.
- Google Cloud, déployer et exploiter des applications d'IA générative. Évaluation, CI/CD, surveillance et cycle de vie.
- OWASP, Top 10 pour les applications LLM 2026.
- OWASP, Top 10 pour les applications agentiques 2026.
- National Bureau of Economic Research, Generative AI at Work. Preuves de terrain sur la productivité du service client.
- Harvard Business School, Navigating the Jagged Technological Frontier. L'expérience menée auprès de 758 consultants.
- UBS, innovation et IA. Résultats communiqués par l'entreprise.
- Siemens, communiqué sur l'Industrial Copilot. Résultat de pilote communiqué par le fournisseur.
- UK Digital Marketplace, service d'IA générative d'IBM. Structure publiée de la découverte et du MVP.
- UK Digital Marketplace, service d'IA générative. Calendrier et prix publiés.
- UK Digital Marketplace, Cloud Data Science AI/ML. Fourchette de prix publiée.
- UK Digital Marketplace, Saracen AI Services. Tarifs journaliers par rôle.