IA en PME : réduire l’empreinte sans sacrifier le service

    Pour rendre un service d’IA plus sobre, une PME doit arbitrer dans le bon ordre : vérifier le besoin, choisir le modèle, puis optimiser son exécution selon les contraintes métier et énergétiques.

    La rédaction DEV N SI3 novembre 20265 min
    Illustration de l’article : IA en PME : réduire l’empreinte sans sacrifier le service

    Pour réduire l’empreinte environnementale d’un service d’intelligence artificielle, la première décision n’est pas de déplacer une charge de calcul vers un autre centre de données : c’est de vérifier si cette charge est nécessaire et quelle solution suffit au besoin métier.

    Dans son compte rendu du 29 octobre 2026, InfoQ rapporte les recommandations de Charles Humble sur l’IA durable, notamment le recours à des modèles plus petits, au calcul dans des régions moins carbonées et au décalage des traitements flexibles.

    Pour une PME, l’enjeu est de transformer ces pistes en arbitrages vérifiables, sans dégrader la qualité attendue ni promettre une baisse d’émissions qui n’aurait pas été mesurée. Le compte rendu situe les émissions du secteur informatique autour de 2 à 4 % des émissions mondiales, selon les propos de Humble. Ce chiffre donne un contexte général ; il ne mesure pas l’impact d’un projet particulier.

    Décision 1 : l’IA est-elle indispensable à ce résultat métier ?

    Commencez par décrire le résultat attendu plutôt que par sélectionner un modèle. Quel travail doit être accompli, pour qui, avec quel niveau de qualité et dans quel délai ? Si une règle, une recherche classique ou une automatisation déterministe donne un résultat acceptable, l’IA peut être superflue. Cette comparaison évite d’ajouter une charge de calcul, une dépendance logicielle et un dispositif de contrôle sans bénéfice métier établi.

    Si l’IA est utile, définissez aussi ce qui constitue une réponse acceptable. Une réponse plus longue ou plus sophistiquée n’est pas nécessairement meilleure pour l’utilisateur. Fixer des critères de qualité et de délai permet ensuite de comparer les options sans réduire l’arbitrage à la seule consommation énergétique.

    Décision 2 : faut-il vraiment entraîner un modèle ?

    Un entraînement spécifique depuis zéro est une option, pas le point de départ par défaut. Charles Humble recommande d’abord d’examiner si un modèle pré-entraîné peut être utilisé tel quel, ajusté, ou sollicité par des instructions.

    Si le service doit s’appuyer sur des documents propres à l’entreprise, la génération augmentée par récupération, ou RAG, consiste à retrouver des informations pertinentes pour les fournir au modèle au moment de répondre. Elle peut donc être une option à évaluer avant un entraînement dédié.

    Lorsque la qualité le permet, réduire la taille du modèle peut aussi diminuer le travail nécessaire à son entraînement et améliorer son efficacité, selon Humble. Il cite la distillation, la quantification et l’élagage comme techniques de compression. Ces options ne sont pas interchangeables : il faut les tester sur les tâches représentatives du service et vérifier qu’elles ne font pas passer la qualité sous le seuil métier défini.

    La comparaison pertinente porte sur le cycle d’usage, pas seulement sur le lancement du projet. Humble souligne que, pour un modèle largement utilisé, l’inférence — le calcul effectué pour produire les réponses — peut représenter davantage d’émissions sur la durée de vie du modèle que son entraînement. Il faut donc examiner les deux postes et éviter de traiter un entraînement ponctuel comme le seul enjeu environnemental.

    Décision 3 : quelle part du calcul peut être déplacée ou adaptée ?

    À quantité d’énergie égale, le coût carbone dépend du lieu et du moment où l’électricité est consommée. C’est l’explication donnée par Humble : l’intensité carbone varie selon les sources d’électricité qui alimentent le centre de données, et fluctue aussi au fil de la journée et de l’année.

    Le décalage de la demande consiste à exécuter une charge flexible à un autre moment ou dans une autre région ; cette approche concerne particulièrement les traitements qui ne sont pas sensibles à la latence, comme l’entraînement.

    Cette option suppose de distinguer les traitements différables des réponses attendues immédiatement. Avant de déplacer un calcul, vérifiez les engagements de service, les contraintes de localisation des données, les dépendances techniques et les moyens de suivre l’exécution. Une région présentée comme moins carbonée ne suffit pas à démontrer le résultat : la décision dépend de l’électricité effectivement utilisée et de la période considérée.

    Autre levier, le « demand shaping » adapte la quantité ou le type de travail fourni selon l’état du service ou de l’électricité. L’exemple rapporté par InfoQ est celui d’un service qui laisse choisir entre une réponse de l’IA et une interaction humaine, ou qui réduit certaines fonctions non essentielles.

    Humble avertit que cette adaptation augmente la complexité et que le niveau de service obtenu doit rester acceptable. Il faut donc définir les cas où le mode réduit s’active, la façon de le signaler et les conditions de retour au fonctionnement normal.

    Chronologie de décision avant le déploiement

    1. Cadrer le besoin. Décrivez le résultat métier, les utilisateurs concernés et les critères d’acceptation. Déterminez quelles tâches peuvent être automatisées sans modèle.

    2. Comparer les architectures. Évaluez, dans cet ordre, un modèle pré-entraîné, son ajustement, le prompting ou le RAG, puis un entraînement spécifique si les autres options ne répondent pas au besoin.

    3. Préparer l’exploitation. Distinguez les calculs immédiats des travaux différables. Évaluez les régions disponibles, les outils de suivi de l’empreinte et les conséquences d’un décalage sur le service.

    4. Valider les compromis. Testez les changements sur des tâches représentatives et comparez la qualité et les délais aux critères convenus. N’attribuez une baisse d’émissions au projet que si elle a été mesurée sur un périmètre explicite.

    Checklist : les décisions à documenter

    • Le besoin métier et les cas où l’IA apporte une valeur identifiable sont définis.

    • Les solutions sans entraînement spécifique ont été examinées avant de lancer un développement de modèle.

    • La qualité attendue, la latence acceptable et les conditions d’un éventuel mode dégradé sont écrites.

    • Les charges pouvant être déplacées dans le temps ou l’espace sont distinguées des traitements immédiats.

    • Les coûts à estimer comprennent le calcul d’entraînement et celui de l’usage courant, ainsi que les moyens de suivi nécessaires.

    • Le prestataire précise les options étudiées, les hypothèses retenues, les critères de validation et les limites des mesures environnementales.

    La sobriété ne se résume donc pas à choisir un fournisseur ou une région : elle dépend aussi du besoin, du modèle et de la manière dont le service répond à ses utilisateurs. Une décision utile pour une PME relie ces choix à des critères de qualité, à des contraintes d’exploitation et à des preuves mesurables, sans confondre une recommandation générale avec le résultat d’un projet particulier.

    Pour cadrer le point de départ, la démarche rejoint celle d’un projet IA commencé par le problème métier : expliciter le besoin avant d’industrialiser la solution.

    Cloud
    Écoconception logicielle
    IA durable
    IA en entreprise
    Sobriété numérique

    Discussion

    Vos retours sur cet article

    Partagez une expérience ou posez une question utile aux autres lecteurs. Chaque message est relu avant publication.

    0 commentaires
    Chargement des commentaires…

    Ajouter un commentaire

    Votre adresse e-mail reste privée.

    0/2000

    Protection Turnstile, limitation anti-abus et publication après validation.