Comment une entreprise suisse choisit-elle le bon modèle IA et le bon vendor ?

Le choix du modèle est une décision métier, pas un détail technique

La question « quel modèle IA choisir ? » est souvent traitée comme un classement : le modèle au meilleur benchmark gagne. Pour les PME suisses, c'est trompeur. Un modèle brillant en tests synthétiques peut échouer sur le cas d'usage réel, enfreindre la protection des données ou coûter bien plus en production. Le choix touche à la fois le droit, les coûts, l'architecture IT et le risque.

Une décision solide part donc non du modèle mais du cas d'usage : que doit faire l'IA concrètement, sur quelles données, pour qui, avec quelle tolérance à l'erreur ? Ce n'est qu'ensuite qu'on pondère les critères et compare les vendors. Ce guide décrit un cadre reproductible plutôt qu'une recommandation éphémère déjà dépassée en quelques mois.

Les cinq critères clés en un coup d'œil

• Aptitude : le modèle résout-il la tâche réelle de façon fiable – langue, domaine, longueur de contexte, outils, vision et couverture multilingue DE/FR/IT/EN ?
• Localisation et souveraineté des données : où les données sont-elles traitées et stockées, qui y accède, l'entraînement utilise-t-il vos saisies, un hébergement suisse ou UE existe-t-il ?
• Modèle de coût et TCO : prix au token, remises volume, coûts fixes de l'auto-hébergement et coûts cachés d'intégration, supervision et maintenance.
• Intégration et exploitation : stabilité de l'API, SDK, latence, disponibilité/SLA, versionnage du modèle et maturité de l'écosystème.
• Conformité et gouvernance : nLPD, règlement européen sur l'IA (extraterritorial), règles sectorielles (ex. exigences FINMA), contrat de sous-traitance, auditabilité et capacité de sortie.

Aptitude : le modèle convient-il à la tâche ?

Les benchmarks publics mesurent l'aptitude générale, pas votre cas d'usage. L'aptitude ne devient parlante qu'avec votre propre petite suite d'évaluation : 30 à 100 exemples représentatifs de votre quotidien avec les résultats attendus. Vous comparez ainsi les candidats à conditions identiques et révélez des faiblesses que les classements masquent – par exemple sur la terminologie suisse, la proximité dialectale ou le vocabulaire métier.

Vérifiez aussi les paramètres cadres : longueur de contexte requise (contrats ou dossiers longs ?), multimodalité (image, PDF, audio), appels d'outils pour l'automatisation, besoins de latence et couverture dans les quatre langues nationales. Souvent un modèle intermédiaire moins cher, avec un retrieval (RAG) propre et de bons prompts, surpasse le vaisseau amiral le plus onéreux.

Localisation et souveraineté des données : le point sensible suisse

Pour les entreprises suisses, la question des données prime souvent sur la performance brute. Quatre points sont centraux : où les données sont-elles traitées et stockées ? Vos saisies servent-elles à entraîner le modèle (généralement désactivable en offre pro) ? Qui peut y accéder légalement ? Et existe-t-il un contrat de sous-traitance selon la nLPD ? Pour des données personnelles ou des secrets d'affaires, ces réponses sont un préalable, pas un bonus.

La nLPD n'exige pas strictement un hébergement en Suisse, mais impose une protection adéquate et de la transparence pour les transferts à l'étranger. De nombreux grands vendors proposent désormais des régions de calcul dans l'UE ou en Suisse ; pour des données très sensibles (santé, finance, secteur public), un hébergement UE/CH ou un modèle open-weight auto-hébergé peut être la solution la plus propre. Des options souveraines suisses et européennes comme le modèle ouvert Apertus d'ETH Zurich et de l'EPFL élargissent le choix au-delà des fournisseurs américains.

Modèle de coût et coût total de possession

Le prix au token visible n'est qu'une partie de la facture. Comparez le coût réel d'exploitation (TCO) sur un volume réaliste : tokens entrée/sortie, taille du contexte, reprises dues aux clarifications, remises de cache et options batch. Un prix d'appel bas peut coûter plus cher, via des prompts longs ou de nombreuses itérations, qu'un modèle apparemment plus onéreux qui résout dès le premier essai. Les prix évoluent souvent – consultez toujours la tarification en vigueur du fournisseur.

Avec l'auto-hébergement, la logique s'inverse : au lieu de prix variables au token, vous portez des coûts fixes d'infrastructure GPU, d'exploitation et de compétences. C'est rentable à volume élevé et constant ou quand la souveraineté des données prime. Intégrez aussi les coûts indirects : intégration, effort de prompt et d'évaluation, supervision, mises à jour de modèles et formation des collaborateurs.

Intégration, exploitation, conformité et sortie

Un modèle ne vaut que par son intégration. Vérifiez la stabilité et la rétrocompatibilité de l'API, les SDK disponibles, la latence et le débit, la disponibilité documentée (SLA) et la maturité de l'écosystème (bibliothèques, communauté, support). La politique de versionnage compte aussi : quand d'anciennes versions sont retirées, il faut réévaluer – planifiez ce cycle de maintenance dès le départ.

Côté conformité, il faut un contrat de sous-traitance selon la nLPD, de la transparence sur les sous-traitants ultérieurs et les transferts à l'étranger, et un classement au titre du règlement européen sur l'IA. Ce règlement est extraterritorial : il peut viser des fournisseurs suisses dont les systèmes sont utilisés dans l'UE ou dont les résultats y sont exploités. Dans les secteurs régulés s'ajoutent les exigences FINMA ou le secret professionnel. Enfin, évitez le verrouillage : privilégiez des standards ouverts, des prompts portables et une architecture qui garde le changement de fournisseur possible.

La grille d'évaluation : pondérer et décider

Traduisez les cinq critères en une grille simple. Pondérez chaque critère selon son importance pour votre cas d'usage (total 100 %), notez chaque candidat sur une échelle de 1 à 5 et multipliez. La décision devient transparente, défendable et auditable – et reproductible à chaque mise à jour de modèle.

• Exemple de pondération (à adapter !) : conformité 25 %, localisation 25 %, aptitude 20 %, coûts/TCO 15 %, intégration 15 % – pour des données très régulées.
• Pilote avant mise à l'échelle : testez les deux meilleurs candidats dans un pilote délimité avec des données réelles avant de vous engager.
• Ne vous liez pas définitivement : gardez l'architecture interchangeable ; le paysage des modèles évolue en mois, pas en années.