Quand votre projet technologique compte vraiment, choisissez l’expérience.

D’une conférence à l’autre, un même discours revenait souvent: avec l’intelligence artificielle, les organisations doivent voir les premiers résultats en quelques semaines, au plus quelques mois. On ne parle plus d’années pour calculer le ROI des initiatives IA.  

Le modèle de développement logiciel est en train de changer en profondeur. Les équipes deviennent plus petites, des agents produisent du code de façon autonome, et le rôle des humains évolue : ils définissent l’objectif, encadrent le travail et vérifient le résultat.  

C’est une transformation que nous vivons chez Spiria. Et nous nous demandons constamment : comment aller vite sans perdre le contrôle?  

ALL IN est venu confirmer qu’e nous allons dans la bonne direction.

Quand est-ce que c’est assez bon ?

Avec l’IA, obtenir un prototype fonctionnel n’a jamais été aussi rapide. Nous pouvons désormais être agiles à l’extrême.

Mais « ça fonctionne » ne veut pas dire « c’est prêt ». Quand des agents génèrent en une journée ce qui exigeait autrefois des semaines, il devient facile de confondre un prototype avec un logiciel terminé.  

Alors, qu’est-ce qui doit être confirmé et vrai avant de pouvoir affirmer qu’une solution est suffisamment solide?

Pour y répondre, on doit penser à ce qui suit le prototype.  

Le premier enjeu est souvent un coût caché à long terme: la maintenance, le support et la fiabilité.  

Si les fondations ne sont pas assez solides, ces coûts ne seront pas nos seuls enjeux. Nous risquons aussi de livrer un logiciel de moins bonne qualité. Et moins bonne qualité est souvent synonyme de vulnérabilité marquée à des potentielles failles de sécurité.  

Il faut donc ajuster les processus pour conserver cette vitesse, tout en misant sur la force de l’équipe. On doit faire intervenir les bonnes expertises, au bon moment, avant le déploiement. L’architecture, la sécurité, la qualité et l’expérience utilisateur doivent entrer dans la boucle avant que le prototype devienne la base d'un produit. Car un logiciel « assez bon » doit être bien programmé, mais surtout, il doit répondre aux besoins des utilisateurs.  

On n’a pas la recette parfaite, mais la ligne d’arrivée ne change pas pour nous. C’est la façon de s’y rendre qui change complètement.

La gouvernance comme accélérateur

On associe souvent la gouvernance à la lenteur et à la lourdeur des processus. Avec l’agentique, elle peut au contraire devenir un accélérateur, c'est la clé pour aller plus vite. Pendant ALL IN, un conférencier l’a résumé ainsi : ce n’est pas la gouvernance qui ralentit l’IA, c’est son absence. Sans cadre, la vitesse gagnée en amont se perd en reprises, en incertitude et, surtout, en confiance.

Et même si on avance plus vite, il faut qu’on avance dans la bonne direction. Justement, une formulation d’une autre conférence, « systems over prompting », illustre bien où nous devons concentrer nos efforts. La performance ne tient pas à la qualité d’une requête isolée. Elle tient au système dans lequel l’agent travaille : des conventions claires, des tests, des étapes de validation bien définies. La gouvernance, c’est ce cadre. C’est elle qui permet aux agents d’aller vite sans dériver.

La responsabilité reste humaine

Un agent peut produire du code, mais il n'en est pas imputable. Dans un projet logiciel, la confiance repose ultimement sur les professionnels qui créent le produit. En opérations, on le sait; quand plusieurs personnes sont responsables de quelque chose, personne ne l’est vraiment. C’est pourquoi chaque agent doit avoir un responsable nommé : une personne, et non une équipe.  Et parce que chaque logiciel que nous livrons est conçu sur mesure, quelqu’un doit aussi, dans chaque projet, valider ce que les agents produisent et pouvoir en répondre devant le client. Livrer, opérer, défendre.

Ce principe dépasse d’ailleurs le code et s’applique aussi à notre rôle de gestionnaires. Ne vous laissez pas tenter de déléguer à l’IA des choses difficiles que l’on devrait faire humain à humain, comme remplacer une discussion délicate par un courriel bien tourné. Une conférencière parlait même d’une forme d’atrophie du leadership. Il y a des tâches, des conversations et des moments qui devraient rester humains. L’IA peut nous aider à nous y préparer. Mais, elle ne devrait jamais avoir une conversation difficile à notre place.

Avancer avec confiance

La vitesse est nouvelle dans l'équation, mais la responsabilité, elle, est toujours la même. Les organisations qui tireront de la valeur de l’agentique seront celles qui sauront accélérer tout en gardant le contrôle sur ce qu’elles produisent, livrent et opèrent.  

Vous aimeriez un coup de main pour utiliser l’IA avec confiance dans vos projets logiciels? Parlons-en.

Le logiciel, capacité critique en défense

On représente souvent la défense à travers ses équipements physiques, alors qu'une part déterminante de ce secteur repose aujourd'hui sur le logiciel, l'intégration de systèmes, les données et l'expérience des personnes qui les utilisent sur le terrain. Cela déplace le risque, puisque la valeur d'un système dépend directement de la qualité de sa conception logicielle et de sa capacité à être déployé et utilisé dans des conditions réelles.

Cette réalité explique aussi la place grandissante des expertises venues d’autres secteurs dans ce domaine. Dans le milieu de la défense, le double usage désigne habituellement une technologie civile réutilisée à des fins militaires, et la même logique vaut pour les savoir-faire, puisque la conception d'interfaces, l'architecture logicielle, la cybersécurité ou l'intégration de systèmes complexes sont des capacités directement transposables, à condition d'être livrées au niveau d'exigence du secteur.

‍

Notre rigueur civile, une capacité de défense prouvée sur le terrain

En défense, la qualité d'un logiciel peut être aussi déterminante que ses fonctionnalités, notamment sa fiabilité et sa simplicité d'utilisation sur le terrain. Les savoir-faire qui le permettent, comme la conception UX/UI, le développement mobile ou la gestion de la sécurité, se sont souvent développés dans le secteur commercial avant de trouver leur utilité en défense.

L'application NORTAC Orion, développée pour Nortac Defence, en est un exemple concret, puisqu'elle transforme un téléphone intelligent en système de suivi, de messagerie chiffrée et d'alerte d'urgence, fonctionnel même hors ligne. Le projet réunissait des exigences typiques de la défense, soit la sécurité des communications, la fiabilité hors connexion et la performance en temps quasi réel, qu'un savoir-faire mobile venu du secteur commercial a permis de satisfaire.

Dans ce marché, les relations et la connaissance de l'écosystème comptent autant que l'expertise technique, car elles conditionnent l'accès aux occasions et raccourcissent des cycles souvent longs. C'est un milieu qui se construit dans la durée, au fil des rendez-vous industriels et des relations avec les donneurs d'ordre, et où Spiria est active depuis plusieurs années, notamment via CADSI.

‍

Ce que livrer en défense exige vraiment

Au-delà de la compétence technique, ce marché ajoute une couche d'exigences qu'une entreprise doit pleinement intégrer, car protéger de l'information sensible transforme la manière de concevoir, d'héberger et de livrer un logiciel. Sur le plan de la sécurité des données, une entreprise logicielle mature applique souvent déjà l'essentiel des standards attendus, comme SOC 2 ou le PCCC qui s'installe peu à peu dans les contrats de défense.

Le facteur le plus souvent sous-estimé se situe du côté de la sécurité physique, puisque l'accès aux locaux, les appareils autorisés, l'environnement de travail et même le réseau peuvent tous être encadrés. Ces exigences demandent du temps et des investissements, et un partenaire crédible les anticipe plutôt que de devoir bâtir cette capacité dans l'urgence, une fois un mandat déjà attribué.

‍

Les certifications, expliquées simplement

Les exigences de certification forment une autre source de complexité, car on imagine souvent qu'il existe une seule accréditation, universelle, qui ouvrirait toutes les portes. La réalité est plus nuancée, puisque les exigences dépendent du mandat et de l'information en jeu, et trois grands mécanismes coexistent au Canada. L'enjeu est double, soit comprendre ce qu'un mandat peut exiger, puis vérifier ce qu'un partenaire détient réellement.

• Programme des marchandises contrôlées (PMC) : il encadre l'examen, la possession ou le transfert de marchandises et de technologies contrôlées, et devient nécessaire lorsqu'un mandat touche ces marchandises ou des documents d'appel d'offres qui en contiennent.
  

• Cotes de sécurité (Programme de sécurité des contrats) : elles donnent accès à de l'information, des biens ou des sites protégés ou classifiés, selon le niveau exigé par le contrat, de la cote de fiabilité jusqu'au Très secret.
  

• PCCC (Programme canadien de certification en cybersécurité) : il atteste que les contrôles de cybersécurité correspondent au risque du contrat, et il s'installe peu à peu dans les appels d'offres de défense, avec un niveau 1 en vigueur depuis 2026.

Retenez surtout que ces mécanismes sont distincts et qu'un même mandat peut en demander un, plusieurs ou aucun. Un bon partenaire vous aide à ouvrir les bonnes portes au bon moment, celles qui correspondent au type de mandat visé, plutôt que d'accumuler des accréditations sans lien avec vos besoins.

‍

Ce qui distingue un fournisseur crédible en défense

Si vous évaluez un partenaire pour un projet logiciel en défense, quelques critères concrets permettent de distinguer rapidement un fournisseur crédible.

• Une expérience réelle en contexte critique ou réglementé. Quels projets comparables ont été livrés, et avec quels résultats?
  

• Une maturité en cybersécurité démontrable. Le fournisseur peut-il fournir une attestation à jour, par exemple SOC 2 de type 2, et ses preuves de contrôles?
  

• La capacité d'ajouter les bons contrôles selon le mandat. Comment adapte-t-il le PMC, les cotes de sécurité et le PCCC au risque du contrat?
  

• La maîtrise de la sécurité physique et des contraintes terrain. Comment protège-t-il l'information sensible dans ses locaux et ses environnements de travail?
  

• Une présence réelle dans l'écosystème de défense. Est-il actif et reconnu auprès des donneurs d'ordre du secteur?

Ces critères valent autant pour un projet de défense que pour tout autre environnement critique, ce qui explique d'ailleurs pourquoi une expertise solide dans un secteur se transpose souvent vers un autre. Un principe résume bien l'entrée dans ce marché, à savoir que les certifications peuvent vous rendre admissible, tandis que les relations vous rendent visible.

‍

En résumé

Entrer dans un projet de défense se prépare avec méthode plutôt qu'avec une course aux accréditations. Les exigences varient selon le mandat, la cybersécurité comme la sécurité physique se vérifient par des preuves concrètes, et la connaissance de l'écosystème pèse autant que les certifications. L'essentiel tient donc à une idée simple, soit évaluer un fournisseur sur son expérience réelle et sa capacité à prouver ses contrôles et à ajouter les bons au bon moment, plutôt que sur le nombre de ses accréditations.

Si vous préparez un projet logiciel dans un environnement complexe et que vous recherchez un partenaire capable de répondre à ces exigences, n’hésitez pas à nous contacter.

Le même scripte, encore et encore

Dès la fin de la première journée de ALL IN, j'ai remarqué que les conférenciers commençaient à se répéter. Peu importe la conférence, le message était toujours une variante de : « L'IA est urgente, elle va tout changer et nous devons préserver notre souveraineté. »

Au début, j'ai cru que cette déception venait uniquement de moi. Je suis d’abord et avant tout un développeur, alors j'avais peut-être simplement envie d'entendre parler de code et de le voir en action. Plus j'écoutais, cependant, plus il devenait clair que ce qu’il me manquait, ce n'était pas tant la profondeur technique, mais plutôt l'expérience vécue. Presque personne n'a expliqué comment l'IA avait transformé sa propre organisation. Tous les médias nous répètent déjà que l'IA est la prochaine grande révolution. Une salle remplie de praticiens devrait donc pouvoir nous apprendre ce que les médias ne disent pas. Par où avez-vous commencé ? Qu'avez-vous essayé ? Qu'est-ce qui a fonctionné, qu'est-ce qui a échoué, et que feriez-vous différemment si vous recommenciez demain ? Je n'ai presque rien entendu de tout cela.

Une grande partie de la programmation portait plutôt sur l'investissement, la gouvernance et la souveraineté des données. Ces sujets sont importants, et certaines de ces discussions étaient excellentes, mais elles restent à haute altitude. Elles nous disent où va l'argent, et très peu sur ce qui se passe quand une équipe s'assoit pour essayer d'utiliser la technologie.

‍

La souveraineté n'est pas la résidence

Certains panélistes ont tout de même dit des choses que tout dirigeant devrait entendre. Et ça m’a fait du bien d'entendre celle-ci à voix haute : la souveraineté des données n'est pas la même chose que la résidence des données.

Beaucoup de gens confondent encore les deux. Un fournisseur vous dit que vos données sont hébergées dans un centre de données canadien. Cela donne une impression de contrôle de la data. Pourtant, l'endroit où vos données sont stockées ne détermine pas qui peut y accéder ni ce qu'ils en font. Des avocats et des fournisseurs d'infrastructure canadiens ont sonné l'alarme : les données détenues par un fournisseur de propriété étrangère peuvent tout de même être assujetties aux lois du pays d'origine de ce fournisseur. L'exemple le plus connu est le CLOUD Act américain, qui peut s'appliquer même lorsque les serveurs se trouvent au Canada.

L'IA ajoute une couche supplémentaire facile à oublier. Une véritable souveraineté nécessite aussi la maîtrise de la façon dont les services d'IA que vous utilisez traitent vos données. Un service qui s'entraîne sur vos informations à mesure que vous l'utilisez ne les oublie pas lorsque vous quittez les lieux, parce qu'il en conserve des traces dans son ADN. La dépendance envers un fournisseur tenait autrefois aux contrats et aux coûts de migration. Aujourd'hui, elle tient aussi à ce que vous lui avez déjà cédé sans vous en rendre compte. Chaque décision concernant un fournisseur d'IA est donc plus risquée qu'elle n'en a l'air.

C'est précisément cette distinction qui donne toute leur importance aux investissements annoncés autour d'ALL IN. Deux jours avant l'événement, Bell a annoncé une expansion de 50 milliards de dollars de son projet de centre de données d'IA en Saskatchewan. Il s'agit du plus important investissement de capitaux privés de l'histoire du Canada. Pendant l'événement, le Canada et l'Allemagne ont engagé de nouveaux fonds pour LoiZéro, un laboratoire qui conçoit une IA digne de confiance, et y ont tenu la première réunion de leur Alliance pour la souveraineté technologique.

‍

Une invitation à expérimenter

J'aurais aimé entendre davantage d'essais et d'erreurs sur scène. Je comprends pourquoi c'est rare. L'IA n'est pas une cible fixe, et ce que l'on dit aujourd'hui peut paraître naïf dans six mois. Partager une expérience qui n'a pas fonctionné demande donc du courage.

L'industrie n'attendra toutefois personne. Des sommes colossales affluent vers les infrastructures, et des actionnaires impatients attendent leur rendement. Si la cible continue de bouger, nos processus doivent bouger avec elle, ce qui exige de réfléchir plus vite et d'expérimenter davantage. Attendre que l'IA soit parfaite pour monter dans le train, c'est s'assurer de ne jamais y monter. Internet n'a jamais été parfait non plus, et pourtant, nous avons réussi à travailler avec.

Alors, commencez maintenant, avec ce que vous avez, et partagez ce que vous apprenez, échecs compris. C'est ce que j'espérais entendre sur scène.

‍

Nous n'avons plus un problème d'IA. Nous avons un problème de talents.

L'idée que j'ai entendu le plus souvent, et celle avec laquelle je suis le plus d'accord, c'est que la technologie n'est plus le goulot d'étranglement. Ce sont les gens. Il nous faut maintenant déterminer comment développer les compétences, les habitudes et le jugement dont nos organisations ont besoin pour bien utiliser ces outils. Le Canada et l'Allemagne ont tous deux fait des talents une priorité, et cette priorité doit maintenant atteindre toutes les équipes, pas seulement les laboratoires de recherche.

Mon côté développeur est resté sur sa faim. Par contre, comme gestionnaire d'une équipe de développement, j'en retire un certain réconfort : personne à l’événement n'a trouvé la formule magique qui rend tout le monde dix fois plus rapide. Une entreprise ne se résume pas à ses développeurs. Et si vous rendez vos développeurs dix fois plus rapides pendant que tout le monde autour d'eux avance au même rythme, ou ralentit en essayant de suivre, et bien, vous n'avez rien réglé. Vous avez simplement déplacé le goulot plus loin dans la chaîne.