Automatisation ou IA?
Choisir consciemment, pas par mode

Module 2 — Choisir entre automatisation classique et IA générative

Ce module pose deux préalables critiques avant toute décision d'adoption d'IA et donne les repères pour choisir entre les deux familles d'outils selon le cas d'usage.

Prérequis : avoir parcouru le Module 1 — Bases de l'IA pour disposer du vocabulaire (LLM, multimodal, cloud vs local, hallucination).

Distinction fondamentale — déterministe vs probabiliste

La distinction entre automatisation classique et IA générative tient à un principe simple : la première est déterministe, la seconde est probabiliste.

• Automatisation classique. Pour la même entrée, le système produit toujours la même sortie. Une règle « si le courriel contient le mot "facture", déposer dans le dossier comptabilité » s'exécute exactement de la même façon mille fois. Les bugs sont traçables (la règle est mal écrite). Le coût marginal d'exécution est presque nul.
• IA générative. Pour la même entrée, le système peut produire des sorties différentes. Demander deux fois à ChatGPT de résumer un texte donnera deux résumés proches mais non identiques. La performance dépend du modèle, du prompt, du contexte. Les erreurs sont moins traçables (hallucination, biais, dérive). Le coût d'exécution est non nul (0,001 à 0,10 $ par appel selon le modèle).

Tableau comparatif :

• Type de tâche. Automatisation : règle déterministe « si X alors Y ». IA : tâche ambiguë, langage naturel, jugement.
• Prédictibilité. Automatisation : 100 %. IA : stochastique — varie d'un appel à l'autre.
• Coût d'exécution. Automatisation : ~0. IA : 0,001 à 0,10 $ par appel.
• Maintenance. Automatisation : faible si les inputs ne changent pas. IA : modèles évoluent, surveillance continue requise.
• Erreurs. Automatisation : bug = règle mal écrite, traçable. IA : erreur = hallucination, biais, drift, moins traçable.

Trois architectures complémentaires

Architecture A — Automatisation classique seule.

Le workflow est entièrement composé de règles déterministes. Aucun LLM n'intervient. Exemple pour un entrepreneur électricien : un formulaire web de demande de soumission → courriel automatique au chargé de soumissions → enregistrement dans le CRM → notification SMS au commercial. Coût quasi nul à l'exécution, prévisibilité totale, audit facile. À privilégier pour 70-80 % des automatisations d'une PME.

Architecture B — Automatisation + IA ciblée.

Le workflow est déterministe en majorité, avec un appel à un LLM à un point précis où la flexibilité du langage naturel apporte une valeur claire. Exemple : courriel client entrant → extraction automatique du sujet et de la pièce jointe (déterministe) → appel LLM pour catégoriser (urgence, type de demande) et résumer en 2 lignes → routage selon la catégorie (déterministe). Le LLM est un module spécialisé, pas la colonne vertébrale du workflow.

Architecture C — Agent IA autonome.

Un système basé sur un LLM exécute une tâche complexe avec peu de contraintes prédéfinies, en décidant lui-même des étapes à suivre et des outils à appeler. Exemple : « Prépare une réponse complète à cette demande de client en consultant l'historique CRM, en récupérant le devis correspondant et en suggérant trois options de prix. » L'agent fait appel à plusieurs outils dans un ordre qu'il choisit. Approche puissante mais plus risquée — à réserver aux cas où l'enjeu de l'erreur est limité ou où la supervision humaine reste systématique.

Plateformes 2026 selon le profil PME :

• Zapier. 9000+ intégrations, le plus simple, no-code, mais pricing par tâche (200 étapes = 200× plus cher qu'1 étape). Pour PME sans équipe technique avec besoins simples.
• Make. Visual scenario builder, 60 % moins cher que Zapier sur logique complexe, courbe d'apprentissage moyenne. Pour PME avec quelques flux structurés.
• n8n. Open source, auto-hébergeable (souveraineté des données — important pour la Loi 25), exécutions illimitées, mais besoin de profil technique. Pour PME avec ressource technique ou volume important.

Pour la majorité des PME québécoises de la construction qui démarrent, Zapier ou Make couvrent les besoins. n8n auto-hébergé devient pertinent quand le volume d'exécutions augmente ou que les exigences de souveraineté des données (clients gouvernementaux, données sensibles) deviennent contraignantes.

Premier préalable — la structure de l'organisation

Pour comprendre concrètement ce que signifie « avoir ses bases », voici les composantes structurelles minimales avant d'intégrer l'IA dans une PME :

1. Processus principaux cartographiés. Pour un entrepreneur électricien : le processus de soumission, le processus de gestion de chantier, le processus de facturation, le processus de service après-vente. Pas besoin de schémas BPMN sophistiqués — un document texte qui décrit qui fait quoi, dans quel ordre, avec quels outils suffit.
2. Outils stables et utilisés. CRM choisi et utilisé par tous (pas trois CRM en parallèle), comptabilité unifiée, espace de stockage de fichiers structuré, outil de communication interne défini. L'IA peut amplifier des outils qui existent — pas combler leur absence.
3. Données de qualité. Le CRM contient les bonnes informations, mises à jour. Les fichiers sont rangés. Les courriels sont triés. Si les données sont chaotiques, l'IA va simplement chercher dans le chaos plus rapidement.
4. Procédures documentées pour les tâches répétitives. Si la procédure existe, l'IA peut la suivre, la rappeler ou l'optimiser. Si elle n'existe pas, l'IA va inventer la sienne, différente à chaque appel.
5. Personnes responsables identifiées. Qui supervise l'usage de l'IA dans l'entreprise? Qui valide ce que l'IA produit avant émission au client? Sans réponse claire, l'usage dérive.

Une PME qui n'a pas ces cinq éléments ne devrait pas intégrer l'IA — elle devrait d'abord les mettre en place. Le retour sur investissement est meilleur, et c'est la condition pour que l'IA produise un effet positif plutôt qu'une couche supplémentaire de désordre.

Second préalable — la conformité Loi 25

Quatre articles de la Loi 25 (LPRPSP) sont systématiquement engagés par l'usage de l'IA. Les avoir traités avant d'adopter un outil d'IA évite que chaque déploiement crée une non-conformité supplémentaire.

• Article 3.3 — EFVP préalable. Une évaluation des facteurs relatifs à la vie privée doit être faite avant d'adopter un outil qui présente un risque pour les RP. Pour l'IA, ce risque est presque toujours présent (nouveaux flux de données, nouveau fournisseur, traitement automatisé). Sans EFVP, l'organisation ne peut pas démontrer sa diligence en cas d'incident.
• Article 12.1 — Décisions automatisées. Si l'IA participe à une décision qui affecte significativement une personne (octroi de crédit, embauche, refus de service), la personne a droit à une information sur les facteurs et la possibilité de présenter ses observations. Cette obligation s'applique avant le premier usage — pas après le premier incident.
• Article 17 — Transferts hors Québec. Tout fournisseur d'IA cloud (OpenAI, Anthropic, Google, Microsoft) traite des données à l'extérieur du Québec. L'article 17 impose une évaluation préalable du cadre juridique du pays d'accueil et des mesures contractuelles équivalentes.
• Article 18.3 — Sous-traitance des RP. Une entente de sous-traitance (DPA) écrite doit être conclue avec chaque fournisseur d'IA qui traite des RP. La majorité des grands fournisseurs proposent un DPA standard — encore faut-il l'avoir signé et l'avoir aligné sur les exigences de la Loi 25.

Pourquoi cet ordre n'est pas négociable : ces obligations existent depuis l'entrée en vigueur de la Loi 25 (2022 et 2023 selon les articles). Adopter un outil d'IA en violation de ces articles ne crée pas un nouveau problème — il révèle un problème antérieur à l'IA. La Commission d'accès à l'information du Québec (CAI) considère qu'une organisation aurait dû régler ces fondations indépendamment de tout projet IA.

Effet pervers de l'inversion : beaucoup d'organisations envisagent l'adoption de l'IA comme l'occasion de « se mettre en règle » — l'inverse est plus prudent. Travailler la conformité Loi 25 d'abord, sans la pression de la mise en production d'un outil d'IA, donne le temps de bien faire. Travailler la conformité au moment où on déploie l'IA crée des compromis sur la qualité de la mise à niveau.

Démarche concrète — grille de décision

Six questions à poser pour chaque cas d'usage :

1. La tâche est-elle suffisamment répétitive pour justifier un effort d'automatisation? Une tâche faite trois fois par an n'a pas besoin d'être automatisée. La règle pratique : 10 occurrences par mois ou plus.
2. Les règles de la tâche sont-elles déterministes? Si oui → automatisation classique (Architecture A). Si la tâche demande de comprendre du langage naturel ou de juger un contexte → considérer l'IA (Architectures B ou C).
3. Quelles données entrent dans le système? Données publiques → liberté. Données internes non sensibles → outil approuvé. Renseignements personnels → vérifier le préalable Loi 25 (Module 4 de la formation).
4. Quel est l'enjeu d'une erreur? Faible (mauvais classement de courriel) → IA acceptable même sans validation. Moyen (devis sous-évalué) → revue humaine systématique. Élevé (décision sur un dossier client, embauche) → IA en suggestion uniquement, décision humaine.
5. Qui est responsable de superviser l'usage? Personne identifiée nommément, pas « l'équipe ». Sans responsable, la dérive est inévitable.
6. Comment mesurera-t-on que ça fonctionne? Indicateur défini avant le déploiement (temps gagné par soumission, taux d'erreur du tri courriel, satisfaction utilisateur). Sans mesure, on ne saura pas si l'investissement a été rentable.

Exemple appliqué — entrepreneur électricien (rédaction de soumissions) :

• Q1 — Répétitif? Oui, 30 soumissions par mois → automatisation justifiée.
• Q2 — Déterministe? Partiellement. La structure (postes, conditions) est déterministe, le contenu (description, choix techniques) demande du jugement → Architecture B (auto + IA ciblée).
• Q3 — Données? Mention du nom et adresse du client (RP) → vérifier que le DPA avec le fournisseur d'IA couvre les RP, et que la politique de confidentialité du site mentionne ce type de traitement.
• Q4 — Enjeu? Moyen. Une soumission mal calibrée a un coût direct → revue humaine systématique avant envoi.
• Q5 — Responsable? Le chargé des soumissions. Identifié, pas « l'équipe ».
• Q6 — Mesure? Temps de production d'une soumission complète, suivi sur 3 mois. Cible : passer de 90 à 30 minutes.

Cette grille n'est pas un formalisme — c'est l'outil qui rend visibles les questions qu'une PME doit régler avant d'investir. Elle fait souvent émerger des préalables (procédure non documentée, DPA absent, indicateur non défini) qu'il vaut mieux régler en amont.

Erreurs fréquentes et pièges à éviter

• ❌ Adopter l'IA sans avoir cartographié les processus. L'IA va amplifier le désordre existant. Ce n'est pas un défaut de l'IA — c'est une erreur de séquence.
• ❌ Utiliser l'IA pour des tâches déterministes. Si la règle existe et qu'elle est claire, l'automatisation classique est plus rapide, plus prévisible, moins coûteuse. L'IA pour ces cas est un excès d'ingénierie.
• ❌ Inverser l'ordre conformité-IA. Lancer le projet IA en se disant « on réglera la Loi 25 en chemin » crée de la pression sur la conformité, qui finit bâclée.
• ❌ Négliger le DPA avec le fournisseur d'IA. Penser qu'un compte ChatGPT Team est suffisant — il faut le DPA signé, et il faut le lire pour vérifier qu'il couvre les RP des clients.
• ❌ Confier l'IA à « tout le monde » sans politique d'usage. Sans encadrement, des employés saisissent des RP de clients dans un compte personnel ChatGPT gratuit. L'organisation hérite de la responsabilité. Le Module 3 développe la politique d'usage.
• ❌ Confondre architecture B et architecture C. Beaucoup d'organisations veulent un « agent autonome » alors qu'un workflow d'automatisation classique avec un appel LLM ciblé suffirait. La complexité non justifiée est coûteuse à maintenir.

L'erreur structurelle la plus fréquente : voir l'IA comme un projet en soi plutôt que comme un outil au service d'un processus. Une PME qui se demande « comment utiliser l'IA » a déjà sauté la première étape — la bonne question est « quelle tâche est suffisamment répétitive et structurée pour bénéficier d'une automatisation, et l'automatisation a-t-elle besoin d'IA pour cette tâche précise? ».