Production : au-delà de la maintenance prédictive
En bref. Lors de la réunion de suivi de production du mois de mars, le responsable d'atelier a relevé que le taux d'arrêts non planifiés stagnait autour de 12 % malgré l'outil de maintenance prédictive installé l'année précédente. Trois usages d'IA plus simples à mettre en œuvre et souvent plus rentables sont : améliorer la prévision des besoins de matières premières, automatiser le traitement des factures fournisseurs et classifier les demandes du service client. Chacun peut être lancé avec des outils déjà présents dans l'entreprise ou des solutions low‑code accessibles.
1. Prévoir les besoins de matières premières avec un modèle léger
Au lieu de chercher à anticiper chaque défaillance machine, il est souvent plus efficace de prévoir les quantités de matières premières nécessaires aux prochaines semaines. Un historique de commandes, de livraisons et de niveaux de stock suffit pour entraîner un modèle de régression simple. On peut commencer avec la fonction FORECAST.LINEAR d'Excel ou avec un notebook Python utilisant la bibliothèque scikit‑learn. L'objectif est de réduire les surstocks et les ruptures, ce qui se traduit généralement par une économie de l'ordre de quelques dizaines d'heures de travail de planification par mois.
- Données nécessaires : historiques de ventes, niveaux de stock, délais fournisseurs.
- Outils : Excel, Google Sheets, ou un script Python léger.
- Compétences : maîtrise de base des formules ou d'un langage de script.
2. Automatiser le rapprochement des factures fournisseurs
La saisie manuelle des factures reste une source d'erreurs et de temps perdu. En utilisant une plateforme d'orchestration low‑code, on peut récupérer les PDF depuis un dossier partagé, extraire les champs clés avec un service de reconnaissance optique de caractères (OCR) et les comparer aux bons de commande enregistrés dans le CRM.
| Plateforme | Points forts | Limites habituelles |
|---|---|---|
| n8n | Open source, nombreux nœuds OCR, auto‑hébergement possible | Installation initiale requise, courbe d'apprentissage des workflows |
| Make (anciennement Integromat) | Interface visuelle très intuitive, bibliothèque de connecteurs riche | Coût d'abonnement selon le nombre d'opérations, moins de contrôle sur l'hébergement |
Dans les deux cas, le workflow peut être testé sur un lot de cinquante factures avant d'être étendu à l'ensemble du flux mensuel. L'effort initial se situe généralement entre huit et seize heures de configuration, puis le traitement quotidien passe de plusieurs minutes à moins d'une minute par facture.
- Données nécessaires : factures PDF, bons de commande dans le CRM (ex. HubSpot ou Salesforce).
- Outils OCR : Google Document AI, Azure Form Recognizer ou même un service gratuit comme
ocrmypdf. - Précaution : vérifier la conformité RGPD avant d'envoyer les documents à un service externe.
3. Classifier les tickets du service client avec un petit modèle de langage
Les équipes support reçoivent souvent des dizaines de demandes par jour, réparties entre suivi de commande, question technique ou réclamation. Un modèle de langage léger, fine‑tuned sur quelques centaines d'exemples étiquetés, peut diriger chaque ticket vers la bonne file d'attente sans intervention humaine.
On peut commencer avec un modèle ouvert comme Mistral‑7B ou Claude‑Instant via une API, ou bien déployer une version quantisée localement si la confidentialité des échanges est critique. L'intégration se fait généralement via un webhook qui envoie le texte du ticket et reçoit une étiquette. Par ailleurs, l'API GPT‑4o de OpenAI offre une option similaire, bien que son coût dépende du volume de tokens.
- Données nécessaires : historique des tickets avec étiquettes (catégorie).
- Outils : API Mistral, API Claude, API GPT‑4o, ou modèle local avec
llama.cpp. - Compétences : capacité à appeler une API REST et à stocker le résultat dans le système de ticketing (ex. Zendesk, Freshdesk).
Le temps de mise en place d'un prototype se situe souvent entre une journée et une semaine, selon la qualité des données d'étiquetage disponibles.
4. Quand ne pas poursuivre l'IA pour la maintenance prédictive
Dans certaines usines, les données de capteurs sont rares, bruyantes ou enregistrées seulement lors des interventions. Essayer d'entraîner un modèle de défaillance à partir de telles séries temporelles conduit généralement à des prédictions peu fiables et à un taux de fausses alertes élevé.
Dans ce contexte, la réponse est « ne le faites pas ». Investir du temps dans la collecte et la nettoyage des données de capteurs serait plus rentable que de développer un modèle prématuré. Une première étape consiste à mettre en place un système de journalisation structurée (par exemple, enregistrer chaque arrêt avec horodatage, code d'erreur et conditions de fonctionnement) pendant au moins trois mois avant d'envisager toute modélisation.
- Signes d'alerte : moins de 500 lignes de données horodatées par machine, présence fréquente de valeurs manquantes.
- Alternative : améliorer les procédures de maintenance préventive basée sur les intervalles d'utilisation ou les contrôles visuels.
- Outils utiles : une simple base de données Excel ou Airtable pour consigner les incidents.
5. Lancer un projet pilote : étapes concrètes
Pour tester l'un des trois usages précédents sans engager de lourds investissements, suivez cette séquence :
- Définir un indicateur simple à suivre (temps de traitement des factures, taux de rupture de stock, délai de réponse aux tickets).
- Extraire un jeu de données représentatif des six dernières semaines.
- Nettoyer les données dans Excel ou Google Sheets (supprimer les doublons, uniformiser les formats).
- Construire un prototype : prévision linéaire, workflow low‑code ou appel d'API de classification.
- Mesurer l'impact sur l'indicateur choisi pendant deux à quatre semaines.
- Si le résultat montre une amélioration notable, prévoir l'extension à l'échelle du service ou de l'usine.
Cette approche permet de valider l'hypothèse d'apport avant de solliciter des budgets plus importants ou de recruter des profils spécialisés.
Questions fréquentes
Quel budget prévoir pour un premier projet d'IA en production ?
Un projet pilote peut être réalisé avec les licences déjà présentes (Excel, un compte CRM) ou avec des abonnements low‑code dont le coût mensuel varie entre vingt et cent euros selon le volume d'opérations. Le principal poste de dépense reste le temps consacré par un employé interne à la mise en place, généralement entre huit et seize heures pour un prototype fonctionnel.
Combien de temps faut-il pour former une équipe interne à utiliser ces outils ?
Pour une utilisation basique d'Excel ou de Make, une demi‑journée de formation suffit à maîtriser les fonctions essentielles. Si l'on opte pour un script Python ou une API de modèle de langage, compter une journée supplémentaire pour comprendre les appels REST et la gestion des clés d'accès.
Faut-il nommer un data scientist dédié dès le départ ?
Non. Les trois usages décrits reposent sur des techniques accessibles à un analyste métier ou à un responsable opérationnel ayant des compétences en manipulation de données. Un data scientist devient pertinent seulement lorsqu'on cherche à développer des modèles complexes sur de gros volumes de données capteurs.
Quelle première action concrète entreprendre demain pour tester l'un de ces usages ?
Commencez par extraire les données de vos bons de commande des trois derniers mois, les nettoyer dans Excel (supprimer les doublons, harmoniser les unités), puis appliquez la fonction FORECAST.LINEAR pour prévoir les besoins du mois suivant. Comparez cette prévision à votre commande réelle et notez l'écart ; cet exercice de trente à quarante‑ cinq minutes vous donnera une base tangible pour décider d'aller plus loin.