Les ratés informatiques de l’État trahissent un problème de structure, pas de technologie
Les récents ratés informatiques au sein de l’État québécois sont souvent attribués à des problèmes techniques. Pourtant, après plus d’une décennie comme consultante en informatique dans plusieurs ministères et plusieurs grandes organisations du secteur des assurances, je vois s’imposer une autre réalité : le problème est d’abord organisationnel.
En début de carrière, dans le secteur privé à Montréal, je prenais en charge l’ensemble du cycle de développement, de l’analyse au déploiement. Cette continuité permettait une compréhension fine des systèmes et une meilleure anticipation des écueils, malgré des estimations déjà souvent optimistes.
Dans les structures gouvernementales et parapubliques, ce cycle est fragmenté. Analyse, développement et tests sont confiés à des équipes distinctes. En théorie adaptée à la complexité des projets, cette spécialisation crée en pratique des vases clos qui nuisent à la cohérence des solutions et qui augmentent les risques d’erreurs et de retards.
Le rôle des analystes illustre bien cette dérive. Trop souvent, ceux-ci n’ont pas pratiqué la programmation depuis leurs études et ne maîtrisent pas les technologies utilisées. Concevoir une solution sans tenir compte des contraintes techniques complexifie inutilement les systèmes, augmente les risques d’intégration et allonge le travail.
À plusieurs reprises, j’ai dû agir comme intermédiaire entre architectes fonctionnels et technologiques, dont les visions divergeaient faute de langage commun. Ce manque d’alignement ralentit les décisions et fragilise les projets.
À cela s’ajoute une distance marquée entre décideurs et équipes de développement. En gestion de projet, on ne peut optimiser que deux des trois paramètres suivants : délais, coûts et qualité. Or, dans plusieurs projets publics, les échéanciers sont fixés d’avance. Les conséquences sont prévisibles : les coûts augmentent et la qualité en souffre.
Les professionnels sur le terrain, soit les analystes, les développeurs, les architectes et les gestionnaires de projet, sont souvent découragés de signaler les risques. Cette culture, qui privilégie le respect des échéanciers affichés au détriment de la transparence, contribue directement aux dépassements.
Elle entraîne aussi des répercussions humaines importantes. Les développeurs, portés par un fort sens des responsabilités, se retrouvent fréquemment sous pression pour compenser des échéanciers irréalistes, au prix de nombreuses heures supplémentaires. Cette intensification du travail augmente les risques d’erreurs, nuit à la qualité de vie et favorise l’épuisement professionnel.
Si l’on souhaite éviter la répétition de situations comme celle de SAAQclic, il faudra s’attaquer aux causes structurelles. Favoriser des équipes intégrées, rapprocher les rôles techniques et décisionnels et valoriser la communication des risques sont des pistes incontournables.
Les difficultés informatiques de l’État ne relèvent pas d’un manque de compétences, mais d’un mode d’organisation qui empêche ces compétences de s’exprimer pleinement.
Ce texte fait partie de notre section Opinion, qui favorise une pluralité des voix et des idées en accueillant autant les analyses et commentaires de ses lecteurs que ceux de penseurs et experts d’ici et d’ailleurs. Envie d’y prendre part? Soumettez votre texte à l’adresse opinion@ledevoir.com. Juste envie d’en lire plus? Abonnez-vous à notre Courrier des idées.
