Intro

Vendredi, 15 h. Votre contrôleuse ressaisit à la main les factures fournisseurs reçues par courriel dans le système comptable. Six heures par semaine. Tout le monde sait que ça devrait être automatisé — quelqu'un l'a même dit en réunion de direction il y a huit mois.

La ressaisie est toujours là.

Ce n'est pas un problème de technologie. Les outils existent et ils fonctionnent. Personne n'a le mandat clair de transformer l'idée en projet, personne ne sait par où commencer, et personne ne veut être celui qui aura dépensé un budget dans un système que l'équipe n'utilisera pas. Voici la démarche que nous appliquons chez Trinary pour éviter ça : ce qui se passe à chaque étape, ce que vous recevez, et où ça s'arrête si vous décidez de ne pas aller plus loin.

Ce qui bloque vraiment l'automatisation dans les PME

Quand un projet d'automatisation échoue, c'est rarement parce que l'outil était mauvais. Les causes qu'on rencontre le plus souvent :

• On automatise un processus jamais documenté. Faute de connaître le vrai déroulement et ses exceptions, on automatise une version idéalisée qui ne correspond à rien.
• On achète l'outil avant de comprendre le besoin. La licence est signée en janvier, le vrai problème apparaît en mars.
• On vise trop gros d'un coup. Un projet de douze mois sur quatre départements a le temps de perdre son commanditaire et son élan avant de produire quoi que ce soit.
• On oublie que quelqu'un devra vivre avec. Formation d'une heure, puis retour à Excel dès la première exception.
• On ne mesure rien. Sans chiffre de départ, impossible de démontrer un gain. Le projet devient une dépense qu'on ne renouvelle pas.

La démarche qui suit désamorce ces cinq pièges, un par un.

Point de départ : une rencontre gratuite de 30 à 60 minutes

Avant de parler de mandat, on se parle. Cette rencontre est gratuite, virtuelle, et elle ne sert pas à vous vendre quelque chose. On y couvre quatre choses :

• Qui vous êtes : votre marché, votre taille, comment l'organisation fonctionne au quotidien.
• Ce que vous avez déjà en tête. La plupart des dirigeants arrivent avec une intuition, parfois un projet amorcé. On part de là.
• Vos outils actuels : ERP, système comptable, CRM, chiffriers, logiciels métier. Ce qui est en place détermine une bonne partie de ce qui est faisable.
• S'il y a un fit. Parfois la réponse est non, ou pas maintenant. C'est une réponse utile, et elle ne coûte rien.

Si la suite a du sens, on vous propose l'un des trois formats ci-dessous.

Étape 1 — Le diagnostic : mesurer avant de proposer quoi que ce soit

Rien ne se conçoit tant qu'on ne sait pas ce qui se passe réellement. Le diagnostic est un exercice d'observation, pas un exercice de vente. On s'assoit avec les personnes qui font le travail — pas seulement leurs gestionnaires — et on examine les processus qui consomment du temps : factures, soumissions, bons de commande, saisie de données, rapports récurrents, suivi des heures.

L'analyse s'appuie sur quatre sources :

• Des entrevues avec les acteurs clés, à tous les niveaux : administration, opérations, techniciens, direction.
• L'observation des outils réellement utilisés, y compris les chiffriers parallèles que personne ne mentionne en réunion.
• L'analyse documentaire des gabarits, formulaires et procédures.
• La validation technique : avant de recommander une intégration, on vérifie que l'API existe, qu'elle est documentée et qu'elle retourne ce qu'il faut. Une recommandation non validée techniquement n'en est pas une.

La logique suit le DMAIC (définir, mesurer, analyser, améliorer, contrôler) : on mesure avant de proposer, et on définit comment les résultats seront contrôlés après. Pour chaque processus, on documente quatre choses :

1. Le volume : combien de fois par semaine, par mois.
2. Le temps réel, reconstitué à partir des systèmes et des personnes — pas estimé en réunion.
3. Le taux d'erreur et le coût du rattrapage : une facture mal saisie, ça coûte combien à corriger en aval ?
4. Les exceptions : les cas qui ne suivent pas la règle et font dérailler la plupart des automatisations.

S'y ajoutent une lecture technologique — ce que vos outils font déjà, ce qui manque — et une lecture des compétences.

À partir du format analytique, cet inventaire devient une cartographie du processus actuel : un diagramme en couloirs montrant chaque étape, son responsable, sa durée, les systèmes et entités externes traversés, et les points d'attente. Les irritants y sont catalogués un par un et classés par impact et par potentiel d'automatisation. C'est un portrait de l'existant, pas une proposition — celle-ci vient à l'étape 2, dans le même mandat.

Trois formats, selon la profondeur nécessaire

Ces formats sont des points de repère, pas un menu fermé : si votre situation tombe entre deux, on construit un mandat sur mesure à partir des mêmes composantes. Les durées varient selon la complexité et les disponibilités — les vôtres, les nôtres, celles de vos partenaires.

Le livrable n'est pas qu'un document : le rapport s'accompagne des cartographies en PDF, consultables et imprimables sans outil particulier. À partir du diagnostic analytique, nous venons présenter les résultats à votre direction et à vos équipes.

Un point important : les étapes 1 et 2 constituent le diagnostic lui-même. Avec un DIAG-1 ou un DIAG-2, le mandat se termine à la livraison du rapport et à sa présentation. Vous décidez ensuite quoi en faire — avec nous, avec votre équipe, ou avec quelqu'un d'autre. Les étapes 3 à 6 s'appliquent si vous allez jusqu'à la mise en pratique.

Étape 2 — Le design : cartographier le processus optimisé

La première cartographie décrit ce qui existe. La deuxième décrit ce qui devrait exister. La distinction a l'air théorique et ne l'est pas : un processus automatisé tel quel, c'est une mauvaise habitude qu'on rend plus rapide.

On produit donc une seconde carte, superposable à la première : ce qui disparaît, ce qui devient automatique, ce qui reste humain, ce qui reste manuel par contrainte externe. Les deux cartes côte à côte, avec les temps de chaque étape, c'est l'argument le plus convaincant qu'on puisse mettre devant une direction.

Le design répond à des questions précises :

• Quelles étapes disparaissent, lesquelles restent humaines ?
• Qui valide quoi, et à quel moment ?
• Quand une exception survient : le système bloque, ou il route vers une personne ?
• Quelles données circulent entre quels systèmes, dans quel sens ?
• Qu'est-ce qu'on ne fera pas dans cette première version ?

Deux principes guident nos propositions.

Une architecture modulaire plutôt qu'un grand système. Chaque module livre de la valeur dès sa mise en production, sans dépendre des autres. Vous validez l'approche sur le premier avant d'investir dans les suivants, vous obtenez des gains dès les premières semaines, et vous étalez l'investissement. Un projet monolithique de dix-huit mois n'offre aucun de ces avantages.

Quand il y a de l'IA, elle propose et l'humain valide. Aucun contenu généré n'entre dans un livrable sans approbation. C'est une question de responsabilité professionnelle, mais aussi d'adoption : les équipes restent auteures de leur travail.

Le découpage vaut de l'or. Un périmètre bien défini, c'est la différence entre une livraison en quelques semaines et un chantier de deux trimestres. Et un design refusé à cette étape coûte quelques jours ; refusé après le développement, il coûte un trimestre.

Étapes 3 et 4 — Le pilote et l'intégration : souvent le même chantier

En théorie, on construit un pilote puis on le branche. En pratique, les deux sont rarement séparables : impossible de valider une automatisation de factures sans accès au système comptable. On développe donc en conditions connectées dès le départ, sauf quand le mandat permet de travailler sur un jeu de données historique ou fictif.

Ce qui caractérise un bon pilote :

• Un périmètre volontairement restreint : un type de document, une équipe, une succursale.
• Un fonctionnement en parallèle du processus existant, pour que personne ne perde son filet de sécurité.
• Un critère de succès défini d'avance. « Traiter 90 % des factures standards sans intervention manuelle » est un critère. « Voir si ça marche » n'en est pas un.

Ce qu'il faut surveiller à l'intégration :

• Les droits d'accès et la sécurité des données : qui voit quoi, où les données transitent, ce qui est conservé. Au Québec, la Loi 25 impose des obligations précises ; ça se règle au design, pas après coup.
• La traçabilité. Quand quelqu'un demande pourquoi une facture a été approuvée, il faut pouvoir répondre.
• La réversibilité. Si le système tombe, l'équipe doit pouvoir reprendre manuellement sans perdre de données.

Le pilote sert aussi à découvrir ce que le diagnostic a manqué — et il en manque toujours : le fournisseur qui envoie ses factures en photo, le code de projet saisi dans le champ des commentaires depuis 2019. Mieux vaut le découvrir sur 5 % du volume que sur 100 %.

Étape 5 — La mesure : les chiffres qui décident de la suite

On reprend les indicateurs collectés au diagnostic et on les compare. C'est la seule façon de transformer une intuition en argument budgétaire. Les indicateurs que nous suivons le plus souvent :

• Temps de traitement par unité (par facture, par soumission, par dossier), avant et après.
• Volume traité sans intervention humaine, en pourcentage.
• Taux d'erreur et coût du rattrapage.
• Délai de bout en bout : combien de jours entre la réception d'un document et sa comptabilisation.
• Taux d'adoption : l'équipe utilise-t-elle le système, ou a-t-elle repris ses anciennes habitudes ?

Ce dernier est le plus souvent oublié. Une automatisation contournée par les trois quarts de l'équipe affiche d'excellentes performances techniques et un rendement réel nul.

Les cibles ne s'inventent pas après coup : elles sont fixées dès le diagnostic, avec valeur de départ et valeur visée. Et quand une donnée manque pour établir une référence fiable, on le dit dans le rapport plutôt que de combler le trou avec une hypothèse déguisée en fait. Une projection bâtie sur un chiffre inventé ne survit pas au premier trimestre. Quand la solution repose sur un modèle de langage, la mesure porte aussi sur la qualité des réponses — un travail continu, pas une validation ponctuelle.

Étape 6 — L'accompagnement : facultatif, mais c'est là que la valeur se construit

Une fois la preuve de concept livrée, vous pouvez vous arrêter là. La plupart des clients continuent, et c'est l'approche que nous privilégions : un POC figé se dégrade, un POC entretenu devient un outil de production. Selon la solution livrée, l'accompagnement peut inclure :

• La formation par le faire, avec les utilisateurs quotidiens, sur leurs vrais dossiers.
• La documentation du processus cible et de la solution, pour que le prochain employé n'ait pas à deviner.
• Les licences, notamment pour couvrir la consommation des modèles de langage.
• L'hébergement et la gestion de l'infrastructure.
• Le support, avec un point de contact clair et un délai de réponse convenu.
• Le développement continu : nouvelles fonctionnalités, nouveaux processus, élargissement à d'autres équipes.

Ces éléments se regroupent en forfait. C'est aussi là que se décide la suite : une fois qu'une équipe a vu un processus fonctionner, la deuxième automatisation se vend toute seule à l'interne.

Votre checklist avant de lancer un projet d'automatisation

À valider avant de signer quoi que ce soit, avec nous ou avec quelqu'un d'autre :

• Une mesure de départ : temps, volume, taux d'erreur, chiffrés plutôt qu'estimés de mémoire.
• Les exceptions du processus visé sont identifiées, pas seulement le cas standard.
• Le périmètre de la première livraison tient sur une page et exclut explicitement certaines choses.
• Un critère de succès écrit, avec un chiffre et une date.
• Les personnes qui font la tâche ont été consultées, pas seulement informées.
• Un responsable interne nommé, avec du temps réellement dégagé.
• Les systèmes à connecter listés, avec leurs accès et limites techniques.
• La conformité traitée au design : Loi 25, conservation, droits d'accès.
• Un plan de repli si le système tombe.
• L'après-livraison au budget : formation, ajustements, support, développement continu.

Si vous cochez la majorité de ces cases, vous êtes prêt à démarrer. Si vous n'en cochez que deux ou trois, ce n'est pas un problème : établir ces réponses fait précisément partie du diagnostic.

Passer de l'idée au résultat

L'automatisation back-office n'a rien de spectaculaire. C'est une suite de décisions ordinaires prises dans le bon ordre : mesurer, concevoir, tester petit, brancher, vérifier les chiffres, accompagner l'équipe. La différence entre une entreprise qui y arrive et une qui en parle depuis huit mois tient rarement au budget ou à la technologie. Elle tient à la méthode.

Si vous reconnaissez votre organisation dans la scène du vendredi 15 h, la première étape n'est pas de choisir un outil. C'est de mettre un chiffre sur ce que ça vous coûte.