IA ouverte ou propriétaire : comment choisir

Définir les termes

L'Open Source Initiative définit l'IA ouverte par les libertés d'utiliser, d'étudier, de modifier et de partager le système, ainsi que par l'accès à la forme préférée pour le modifier. Le terme « open weights » indique seulement que les poids sont disponibles ; il ne garantit ni les données, ni le code, ni la licence, ni une liberté suffisante pour parler d'ouverture au sens strict.

Propriétaire peut désigner une API fermée, un modèle sous licence commerciale ou une plateforme gérée. Dans chaque cas, il convient d'analyser le contrat exact.

Comparatif

Il n'existe pas de vainqueur universel.

Licence

Il convient de vérifier :

• Usage commercial.
• Restrictions de secteur ou de taille.
• Redistribution.
• Modification.
• Obligations d'attribution.
• Usage des sorties générées.
• Brevets.
• Évolutions futures de la licence.
• Licence des données et du code.

Un téléchargement gratuit n'accorde pas de droit à tout usage.

Qualité sur des tâches réelles

Elle s'évalue avec un jeu de tests propre mesurant :

• Exactitude.
• Fidélité.
• Langue et terminologie.
• Format.
• Abstention.
• Sécurité.
• Latence.
• Coût.

Les benchmarks publics orientent, mais ne remplacent pas les tests sur les documents, les clients et les outils réels de l'entreprise.

Données et confidentialité

Pour une API propriétaire, il faut examiner la rétention, l'entraînement, la région, le support, les sous-traitants et les transferts. Pour un déploiement propre, il faut contrôler l'infrastructure, les journaux, les sauvegardes, les administrateurs et la suppression.

Auto-héberger le modèle n'élimine pas le RGPD. L'organisation devient simplement opératrice de davantage de composants.

Sécurité

Ouverte

• Provenance des poids.
• Intégrité et signature.
• Dépendances.
• Vulnérabilités.
• Code d'inférence.
• Isolation.
• Mises à jour.

Propriétaire

• Identité et permissions.
• Régions.
• Changements silencieux.
• Abus de l'API.
• Disponibilité.
• Chaîne de fournisseurs.
• Exportation.

Les deux options exigent des tests adverses.

Coût total

Ouverte :

• GPU/CPU.
• Énergie.
• Stockage.
• Ingénierie.
• Disponibilité.
• Supervision.
• Mise à jour.
• Sécurité.

Propriétaire :

• Tokens.
• Appels.
• Stockage.
• Connecteurs.
• Limites.
• Support.
• Sortie de données.
• Dépendance.

Le coût se calcule par tâche valide, pas par token ni par GPU.

Performance et échelle

Un petit modèle local peut suffire pour la classification ; un modèle avancé via API peut apporter de la valeur sur un raisonnement complexe. Une architecture de routage peut sélectionner le modèle selon le risque et la difficulté de chaque tâche.

La décision peut être hybride :

• Local pour les données sensibles.
• API pour le contenu public.
• Solution de repli (fallback).
• Passerelle commune.
• Évaluation et format stables.

Dépendance et portabilité

Le lock-in se réduit avec :

• Une interface propre.
• Des prompts et des tests versionnés.
• Des données séparées.
• Des formats standard.
• Des fournisseurs alternatifs.
• Des tests périodiques de substitution.
• Un contrat de sortie.

Changer de modèle n'a rien de trivial : le comportement et les coûts varient. L'évaluation automatisée permet de comparer les alternatives.

Transparence et explicabilité

Accéder aux poids n'explique pas une réponse. Une transparence utile couvre les données, la finalité, l'évaluation, les limites et l'exploitation. Un fournisseur fermé peut offrir une documentation solide ; un modèle ouvert peut en être totalement dépourvu.

Ce qui compte, c'est la preuve, pas l'étiquette.

Exploitation

Avant d'auto-héberger, il convient de confirmer :

• Personnel 24 h/24 et 7 j/7 si nécessaire.
• Application des correctifs.
• Capacité.
• Montée en charge.
• Observabilité.
• Gestion des incidents.
• Reprise.
• Retrait.

Si l'organisation ne peut pas le maintenir, le contrôle théorique devient un risque.

Matrice de décision

Les poids s'adaptent à chaque cas.

Plan de test

1. Définir les cas et les critères de décision.
2. Sélectionner deux ou trois candidats.
3. Exécuter le même jeu de tests sur chacun.
4. Mesurer la qualité, le coût et la latence.
5. Revoir la sécurité et la licence.
6. Tester l'exploitation et la sortie.
7. Décider et consigner les conditions.

Erreurs fréquentes

1. Appeler open source ce qui n'est qu'open weights.
2. Choisir en se fiant aux seuls benchmarks.
3. Ignorer la licence.
4. Comparer le coût par token au coût du matériel.
5. Supposer que le local est sécurisé par défaut.
6. Ne pas tenir compte de l'exploitation.
7. Dépendre d'une API sans plan de sortie.
8. Faire un fine-tuning sans jeu de tests.
9. Ne pas suivre les changements du fournisseur ou du modèle.
10. Choisir un seul modèle pour tout.

Checklist

• Définition et licence.
• Cas d'usage réels.
• Qualité et abstention.
• Données et confidentialité.
• Sécurité.
• Coût total.
• Capacité opérationnelle.
• Portabilité.
• Fournisseur alternatif.
• Décision versionnée.

Questions fréquentes

L'open weights est-il identique à l'open source ?

Pas nécessairement. Les libertés et la disponibilité définies par l'Open Source Initiative doivent être respectées.

L'IA ouverte est-elle toujours moins chère ?

Pas toujours. Elle peut supprimer la consommation par API, mais elle ajoute une infrastructure et une équipe propres.

L'IA propriétaire est-elle toujours plus sûre ?

Pas par définition. Cela dépend des contrôles, du contrat, de la configuration et des preuves disponibles.

Peut-on combiner IA ouverte et IA propriétaire ?

Oui. Une architecture hybride peut router chaque tâche selon sa sensibilité, son coût et sa difficulté.

Summum IA compare les modèles ouverts et propriétaires avec sa propre évaluation, le coût total et l'architecture de sortie avant de recommander une solution.