Une mission de conseil en IA peut couvrir le choix d'un cas d'usage, l'évaluation des données, le développement et l'intégration d'une application, puis son exploitation. Pour une entreprise suisse, elle doit aussi préciser les exigences de protection des données et les responsabilités après la mise en service. Le périmètre de ces prestations explique une grande partie des écarts de prix entre les offres.
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.
Pour comparer les cabinets, demandez les livrables de chaque phase, leur propriétaire et les compétences qui seront transmises à votre équipe. Ces éléments vous aideront à juger l'offre au-delà du choix du modèle.
Évaluer les capacités de l'IA sur vos tâches
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 points de pourcentage de chances en moins d'aboutir à la bonne réponse.
Ces résultats varient selon la tâche. Une réponse bien formulée peut être erronée, même si le modèle a réussi les cas précédents. Le prestataire doit donc tester votre cas d'usage sur des exemples représentatifs, identifier les erreurs et préciser les contrôles nécessaires.
On peut en tirer un principe simple pour choisir un partenaire :
Une mission utile répond à des questions précises sur la valeur du projet, ses données, son architecture ou son exploitation. Ses résultats doivent permettre à votre équipe de décider de la suite et de reprendre le travail.
Ce que vous devez obtenir à chaque phase
Les phases ci-dessous peuvent relever d'une même mission ou de mandats distincts. Pour chacune, convenez du résultat attendu et des éléments remis à votre équipe. La gestion des risques doit se poursuivre pendant tout le projet : le cadre du NIST organise ce travail autour de la gouvernance, de la cartographie, de la mesure et de la gestion.
Faites défiler le tableau horizontalement pour voir toutes les colonnes.
| 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é, solutions de secours, 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 réaction aux entrées malveillantes 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, résultats des simulations d’attaque, 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 prévoir l'importation et la mise à jour des documents, leur découpage, les métadonnées, le respect des autorisations et des sources vérifiables. Demandez comment la qualité de la recherche est mesurée séparément de celle de la réponse : cela permet de savoir si une erreur vient des documents retrouvés ou de leur interprétation. Les recherches supplémentaires, les représentations vectorielles et le contexte ajouté au prompt doivent aussi entrer dans le calcul du coût et du temps de réponse.
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, utilisables licitement et suffisamment fiables ? Sinon, commencez par leur préparation et leurs conditions d'accès.
- 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 responsable 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équences importantes 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.
Faites défiler le tableau horizontalement pour voir toutes les colonnes.
| 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.
Combien coûte une mission de conseil en IA ?
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. Ces tarifs catalogue décrivent des offres britanniques précises. Ils donnent des repères sur la composition des équipes, mais ne permettent pas d’estimer directement le prix d’une mission en Suisse.
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.
Prévoyez dans le contrat une décision de poursuite ou d'arrêt après le prototype.
À 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.
Délais : du cadrage à la mise en production
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.
Pour préparer un calendrier chez Alpine Edge, nous utilisons les plages indicatives suivantes, à confirmer pour chaque mission. 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.
Ces durées servent à préparer un calendrier initial. Les applications réglementées, les modèles d'apprentissage automatique 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
- Obligations réglementaires identifiées
- Liste explicite de ce qui ne sera pas construit
- 023–8 semaines
Un MVP ciblé
- Premier parcours complet avec ses intégrations
- Jeu d'évaluation et seuils d'acceptation
- Limites documentées
- Décision de poursuite fondée sur des preuves
- 034–12+ semaines
Préparation à la production
- Authentification, autorisation, gestion des secrets
- Supervision, secours 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.
Faites défiler le tableau horizontalement pour voir toutes les colonnes.
| 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 environnement d’exécution, 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 |
L'auto-hébergement ne suffit pas à assurer la conformité. Il faut examiner la manière dont les données personnelles sont traitées, les finalités, les droits d'accès et les prestataires concernés. Un système RAG installé dans votre centre de données peut lui aussi divulguer des informations confidentielles si ses permissions sont mal configurées.
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.
Faites défiler le tableau horizontalement pour voir toutes les colonnes.
| Domaine | La question | Ce que contient une bonne réponse |
|---|---|---|
| Intérêt économique | 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 d’attaque |
| Sécurité | Comment traitez-vous l'injection de prompt et les fuites de données ? | Modèle de menaces, simulations d’attaque, 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, solutions de secours, 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.
Résultats publiés chez UBS et Siemens
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 chargés 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.
Définissez dès le départ qui prendra en charge les évaluations, les incidents et les mises à jour après le lancement.
Alpine Edge propose du conseil en IA en Suisse, du cadrage à l'intégration logicielle. Nous examinons avec vous la valeur du cas d'usage, les données disponibles et les contraintes techniques. Une évaluation technique ciblée permet de décider de la suite ; les cas retenus sont accompagnés du cadrage à l'exploitation, en passant par l'architecture et l'intégration.
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.