Recherche et développement expérimental

Déverminage & Troubleshooting avancé

Quand les solutions évidentes ne suffisent plus

Parfois, les solutions ont besoin d'être inventées

Quand un système bloque ou qu’une idée technique sort des sentiers battus, une approche standard ne suffit plus.

Nous intervenons dans les situations où :

  • l’incertitude est élevée

  • un idée doit être validée avant d'investir d'avantage

  • les solutions traditionnelles ont échoué

  • une validation rapide est nécessaire.

  • deux systèmes n'ont pas été conçu pour se parler


Notre rôle est de réduire rapidement l'incertitude technique et apporter une direction claire

Ce que ce service n'est pas

Ce service n'est pas du développent standard.


Il s'adresse aux situations où:

  • le chemin n'est pas connu

  • une exploration est nécessaire

  • une expertise architecturale est requise.

Qu'est-ce que la recherche expérimentale?

Explorer avant d'investir - Réduire les incertitudes

La recherche expérimentale vise à valider des hypothèses techniques à travers des preuves de concept (POC).

  • explorer des solutions nouvelles

  • valider des hypothèses techniques

  • construire des preuves de concept (POC) ou un produit minimum viable (MVP).

Exemples :

  • Connecter 2 API sans intégration native

  • tester une architecture non documentée

  • évaluer la faisabilité d'une automatisation complexe

L'objectif est de trouver rapidement ce qui fonctionne... et qui ne vaut pas la peine d'être poursuivi.

Dans les contextes d’incertitude élevée, la vitesse de compréhension devient votre plus grand avantage

Troubleshooting avancé

Quand le système fonctione... mais pas vraiment

Nous intervenons lorsque:
  • le système est instable ou incompris
  • plusieurs intégrateurs ou développeurs ont laissé des traces
  • la dette technique bloque l'évolution
  • les erreurs disparaissent quand on essaie de les reproduire
  • des experts qui tournent en rond pendant des semaines sans trouver la source du problème.

C'est là qu'on nous appelle.

En quelques heures (ou parfois en quelques minutes), nous mettons le doigt sur la cause du problème et faisons économiser des milliers, voire des millions de dollars en pertes de temps et d’opportunités (sans exagération, c'est arrivé à plusieurs reprises!).

Lorsque les solutions évidentes ne suffisent plus, notre rôle est d'apporter rapidement une direction claire

Différence avec le développement et l'intégration traditionnels

Lorsqu'on parle de développement ou intégration standard, on parle d'activités où l'incertitude est relativement minime:
  • solutions, plateformes ou "pattern" connus
  • plan d'architecture défini et prévisible
  • implémentation personnalisée

La recherche ou le développement expérimentale, quant à eux, surviennent lorsqu'il y a:
  • incertitude élevée
  • exploration 
  • prise de décision stratégique.
Cette situation survient souvent lorsque le processus, la méthode ou le système n'existe pas.

Construire une maison en bois est beaucoup plus prévisible que de construire une base spatiale sur Mars.

Passage vers le développement et l'intégration

Une fois la preuve de concept validée :

  • le projet peut passer en mode développement ou intégration standard.

  • ce travail peut être réalisé par vous, par notre équipe ou un partenaire selon la nature du mandat.


Cela permet de:
  • d'optimiser les coûts
  • d'utiliser la bonne expertise au bon moment
Intégration et développement

Quand faire appel à nous?

  • Vous avez déjà investi sans obtenir résultats clair
  • Vous sentez que la solution existe mais reste floue
  • Vous voulez éviter des mois d'essaie et erreurs.

Fonctionnement et prix

Dans les contextes d'urgence ou d'incertitudes élevée, il est impossible de prédire la durée totale nécessaire à l'atteinte d'un résultat.


Nous travaillons par blocs d'exploration itératifs permettant:

  • d'avancer rapidement
  • de tester des hypothèses
  • de prendre des décisions éclairées.


Chaque bloc vise à réduire vos risques, réduire l'incertitude et clarifier la prochaine étape.

Les blocs d'une journée peuvent être utilisée de façon flexible (ex: 2 demi-journées)


Le troubleshooting/déverminage est, quant à lui, à taux horaire.


Nous ne vendons pas un résultat garanti, nous vendons une progression maîtrisée dans l’incertitude.


"Vous n'achetez pas simplement du temps de développement"

Vous investissez dans une réduction rapide du risque technique et des erreurs stratégiques

Votre problème ressemble-t-il à ceci?

  • Vous êtes arrivé à la limite de votre système – Vos systèmes ne s'intègrent pas comme vous voulez
  • Un système qui "fonctionne... parfois" – Des erreurs intermittentes qui reviennent sans raison apparente. 
  • Un projet bloqué sans explication claire – Après des semaines de travail, personne ne trouve la cause. 
  • Des consultants experts qui cherchent, mais ne trouvent pas – Parce qu’ils connaissent l’outil, mais pas forcément comment tous les systèmes interagissent ensemble
  • Un enchevêtrement de logs incompréhensible – Trop d’informations, sans moyen efficace de les analyser.

Si ces scénarios vous parlent, c’est probablement que vous avez besoin de spécialistes du déverminage.

Pourquoi sommes-nous efficaces là où d’autres échouent?

Nous analysons le problème en profondeur pour identifier les meilleures stratégies d’automatisation et d’intégration, en utilisant les bonnes technologies et en optimisant votre infrastructure TI.

Une approche méthodique et scientifique**

Nous n’avançons jamais au hasard. Notre approche repose sur la logique, la structure et la corrélation des données:

  • Observation minutieuse des symptômes – Repérer les petits indices que d’autres ignorent.
  • Collecte automatisée de données – Plutôt que de naviguer dans un océan de logs, nous analysons uniquement ce qui est pertinent en croisant les informations de différents systèmes.
  • Établissement de cause à effet – Grâce à une vision globale des systèmes, nous détectons les interactions invisibles qui provoquent l’anomalie.

Une vision large et transversale des technologies

La plupart des experts sont spécialisés dans un domaine spécifique (AD, Exchange, Intune, DNS, sécurité, Systeme d'exploitation, CRM, etc.). Ce qui nous distingues, c'est que nous avons une approche où la compréhension globale et interconnectée des systèmes, ce qui nous permet d’identifier des causes que d’autres ne voient pas.

L’obsession de la résolution

Quand un problème nous résiste, nous ne lâchons pas le morceau. Là où d’autres finissent par abandonner ou contourner le problème, nous allons au fond des choses jusqu’à l’élimination définitive de la cause racine.

Un retour sur l'investissement

Dans les grands projets d’infrastructure, la phase la plus critique n’est pas la construction elle-même, mais la compréhension des contraintes invisibles avant même de commencer.

En développement expérimental autant qu'en troubleshooting, c’est exactement la même chose : on ne commence pas par coder, on commence par comprendre les systèmes en jeu et valider les hypothèses.


Notre travail, c’est exactement ça! 


Vous avez les choix:
  • Vous passez des jours, des semaines, voire des mois à chercher une solution… 
  • Votre projet reste bloqué pendant des semaines, monopolisant du personnel et coûtant des dizaines de milliers de dollars.
  • Un coût opérationnel où une dette technologique reste en place pendant des années

                ou

Nous trouvons une solution et votre entreprise gagne en efficacité et en rentabilité immédiatement.

Pourquoi fonctionner par bloc itératifs?

Ajouter de la prévisibilité dans l'imprévisibilité

En découpant l'approche par bloc, votre engagement est limité à la portée que vous désirez.

Vous passez plus vite en mode solution

Une fois la solution trouvée, le POC ou MVP réalisé, il ne reste qu'à implanter. Ça sera à vous de choisir la voie à choisir pour le déploiement ou l'implantation.

L'incertitude

Vous payez pour une résolution efficace, pas pour du temps perdu en débats d'opinions. Si nous n’apportons pas de valeur, vous le verrez immédiatement. Il n'y aura pas d'hémorragie budgétaire!


Types de problèmes que nous résolvons

  • Applications d’entreprise (Office 365, Intune, Azure, Zoho, ERP, CRM…) 
  • Intégration API et transformation de données 
  • Infrastructure et réseaux (DNS, Firewall, routage, IPv4/IPv6, hébergement web) 
  • Déverminage de code (C#, PowerShell, JavaScript/TypeScript) Problèmes de performance, intération entre composantes,...
  • Automatisations et scripts (problèmes de processus internes, erreurs systèmes) 
  • Sécurité et permissions (accès, authentification, MFA, SSO) 
  • Problèmes intermittents & bugs incompréhensibles

Il est impossible de tout lister

Questions et réponses

Si mon équipe trouve la solution elle-même, pourquoi est-ce que je dois payer le service?

Parce que souvent, notre rôle est d’être le catalyseur de la solution.
Lorsque l'on pose des questions comme "Est-ce que l’entrée DNS existe?", cela peut amener l’administrateur en place à réaliser un oubli. Même si ce n’est pas nous qui, techniquement, effectue la correction directement, c’est notre expertise qui a permis de la détecter rapidement. La bonne nouvelle est que votre engagement se limite aux blocs consommés.

Pourquoi est-ce que le diagnostic peut prendre plusieurs heures sans résultats visibles?
Parce que trouver un problème complexe demande une méthodologie rigoureuse.
Chaque client est unique, toutes les configurations sont différentes.
Les problèmes intermittents ou les bugs aléatoires nécessitent une analyse en profondeur. Ce travail implique :
  • Collecte de logs
  • Tests en conditions réelles
  • Vérification des configurations
  • Hypothèses et validation

Même si aucun correctif n’est appliqué immédiatement, chaque test élimine une cause possible, rapprochant ainsi la solution finale.

Est-ce que vous garantissez de trouver la solution à mon problème?
Nous ne pouvons pas garantir une résolution immédiate, mais nous pouvons garantir une approche méthodique et efficace.
Certains problèmes nécessitent des tests prolongés ou la collaboration avec d’autres intervenants (ex. support technique du fournisseur). Ce que nous garantissons, c’est que nous allons épuiser toutes les pistes possibles avec la plus grande efficacité.
Si la solution est hors de notre portée, si nous déclarons forfait ou même si vous n'êtes pas satisfait de notre méthode, vous serez facturé que pour les blocs consommés.
Comment déterminer si je suis dans un forfait "Développement et intégration" versus le mode "Recherche, développement expérimental et troubleshooting"?

L'approche est complètement différente. Dans un mode de développement et d'intégration traditionnel, nous travaillons avec un plan et une direction et souvent selon des pratiques et des patterns déjà établis. La partie "incertitude" occupe une place moindre dans le travail. Nous connaissons la destination et nous savons généralement quelle route à prendre pour y parvenir.


Pour reprendre l'analogie précédente, en mode recherche scientifique, développement expérimental ou troubleshooting, nous avons une idée de la destination, mais nous ne connaissons pas la route. Certaines fois, il faut même construire le moyen de transport pour s'y rendre. Nous avançons méthodologiquement, mais l'incertitudes empêche l'établissement d'un plan clair. Nous collectons des données et des idées jusqu'à trouver une solution. Parfois l'urgence est telle, que nous devons mettre sur pause nos autres clients pour vous aider rapidement.

Pourquoi votre service est plus cher que celui d’un technicien généraliste
Parce que nous ne faissons pas qu'exécuter des tâches, nous créons des solutions et du temps

  • Un technicien généraliste applique souvent des solutions standards.
  • Notre expertise nous permet de comprendre les systèmes en profondeur et de détecter des causes cachées.
  • En nous engageant, vous évitez de perdre des semaines à chercher une solution*.
*La référence à un problème DNS à la première question n'est pas un hazard. C'est un cas réel survenu récemment chez un client. Un projet de déploiement  était bloqué et les gens en place ont cherché le problème pendant 3 semaines avant de nous contacter. Il manquait réellement qu'une simple entrée DNS! La solution était simple. La trouver l'était moins.
Pourquoi ne puis-je pas simplement chercher la solution sur Google, ou encore mieux sur ChatGPT ou autre?
Vous pouvez! C'est ce que les gens font avant de nous appeler! Toutefois, chaque problème est unique et les solutions génériques ne s’appliquent pas toujours.
  • Google donne des solutions pour des cas communs, mais un problème réseau, système ou logiciel peut être spécifique à votre infrastructure.
  • La compréhension du contexte et les observations font toute la différence.
  • L’expérience compte : des problèmes, nous en avons vu de toutes les couleurs! (Note de l'éditeur: On ne parle pas de 2 ou 3 ans à bidouiller ici et là... on parle ici de 35 ans de cas réels affrontés avec passion. Nous savons comment tester rapidement les bonnes pistes.)
  • Nous utilisons Google et les dernières technologies aussi :-)
Pourquoi le problème est-il revenu après votre intervention?

Plusieurs causes possibles :

  • Une autre cause sous-jacente qui n'était pas visible lors du premier diagnostic.
  • Un changement dans l’infrastructure après notre départ.
  • Un problème intermittent qui nécessite un suivi plus long.

Si un problème revient, nous recommandons une analyse plus approfondie ou la mise en place d’outils de surveillance pour capturer l’anomalie lorsqu’elle se produit.

Pourquoi le troubleshooting est-il parfois plus long sur certains environnements?
Parce que chaque infrastructure est différente et certaines sont plus complexes que d’autres.
  • Un environnement mal/moins documenté ou compliqué peut ralentir le diagnostic.
  • Les systèmes "legacy" peuvent présenter des comportements imprévisibles. Par exemple une nouvelle itération d'une application "frontend" qui ne supporte pas d'anciens protocols moins sécuritaires. Un bel exemple simple et concret est la nouvelle version de Outlook qui en fin 2024 a cessé de supporter d'anciennes versions du protocol IMAP.
  • Certaines entreprises utilisent des configurations non standards qui nécessitent plus de temps d’investigation.
Quelle est la différence entre troubleshooting, diagnostic et correction?
Ces trois étapes sont distinctes et chacune a son importance.
  • Troubleshooting = Identification du problème (ex. "Pourquoi le serveur plante-t-il?")
  • Diagnostic = Déterminer la cause (ex. "C’est un problème de permissions sur un fichier critique.")
  • Correction = Appliquer la solution (ex. "On rétablit les bonnes permissions et on surveille.")

Notre travail est d'identifier la cause du problème. Dans certains cas on corrigera le problème à la demande du client. Parfois, une fois le problème identifié, le client jugera qu'il peut faire la correction lui même. Surtout dans des environnements "plus complexe" (une banque par exemple où la sécurité prime sur tout), la correction sera effectuée à l'interne par l'entité compétente. 

Pourquoi me recommandez-vous parfois de changer d’outil ou de solution?
C'est relativement rare, mais parfois certaines infrastructures ne valent pas la peine d’être réparées.
  • Si un problème est récurrent et coûte plus cher à corriger qu’à remplacer, je recommande une solution alternative plus efficace. ex: Un client qui utilise le même hébergement courriel depuis 20 ans et que ce dernier ne fonction qu'avec IMAP et en plus, il ne respectent pas les derniers standards... là on n'a pas le choix!
Combien de temps faut-il pour trouver la cause d’un problème?
Ça dépend de la complexité du problème.

Certains problèmes peuvent être résolus en quelques minutes, d’autres nécessitent des analyses plus longues :

  • Problème évident (ex. compte de service avec mot de passe expiré): 15 min
  • Bug logiciel intermittent: Quelques heures à plusieurs jours
  • Problème réseau complexe (ex. latence aléatoire, problème impliquant des logiciels "maison"): jusqu'à plusieurs semaines
Est-ce que vous formez mes équipes après avoir trouvé la solution?
Oui, et c’est fortement recommandé!

Tout au long du processus, nous prenons des notes. Après la résolution d’un problème, nous produirons généralement un rapport :

  • Documenter la solution qui pourra être utilisé pour former votre équipe et pour qu’elle soit autonome.
  • Proposer des améliorations pour éviter que le problème ne se reproduise.
  • Mettre en place des outils de monitoring pour détecter les anomalies plus tôt.

Une bonne documentation et une formation permettent d’économiser des milliers de dollars à long terme!

Pourquoi est-ce que la première intervention prend souvent plus de temps?
Parce qu’en tant que consultants externes, nous devons d’abord comprendre votre environnement et gagner votre confiance.
  • Lors de notre première visite, nous devons nous adapter à votre infrastructure, vos processus et votre équipe.
  • Souvent, les collaborateurs hésitent à partager certaines informations par crainte d’être jugés ou remis en question.
  • Il faut aussi vérifier les accès, obtenir les permissions, comprendre l’historique des incidents.

Avec le temps, la relation de confiance s’installe et nos interventions sont plus rapides et efficaces.

Pourquoi est-il important d’être totalement transparent avec nous dès le début?

Parce que plus nous avons d’informations, plus nous pouvons être efficace.

  • Certains pensent que cacher des erreurs passées ou des configurations bricolées peut éviter d’être blâmé.
  • En réalité, mon rôle n’est pas de pointer du doigt, mais de trouver une solution efficace. On l'a vu souvent, en informatique, une solution est implantée temporairement de façon permanente 😁.
  • Si nous devons deviner ou tester à l’aveugle, le processus sera plus long et plus coûteux.

Si vous nous donnez l’information complète dès le départ, nous gagnons du temps et trouvons la solution plus vite.

Pourquoi est-ce que mon accès aux systèmes est souvent un frein au diagnostic?

Parce qu’en tant qu’externe, je ne peux pas accéder immédiatement à tout ce qui est nécessaire.

  • Les équipes IT internes doivent souvent valider les accès, ce qui peut ralentir le troubleshooting.
  • Certaines entreprises n’ont pas de documentation claire sur leur infrastructure, ce qui rend la tâche encore plus difficile.
  • Dans certains cas, des décisions de sécurité (ex. accès restreint aux logs) empêchent une analyse rapide.

Tout ça est normal, c'est ce que nous vivons normalement. Quand nous revenons pour une autre intervention, ces barrières sont levées, ce qui rend la résolution des problèmes beaucoup plus rapide.

Pourquoi est-ce que les équipes internes peuvent être réticentes à ma présence?

Parce que l’intervention d’un expert externe peut être perçue comme une remise en question du travail en place.

  • Certains employés craignent d’être critiqués ou de voir leurs erreurs exposées.
  • Il peut y avoir une réticence naturelle à collaborer avec un intervenant externe qu’ils ne connaissent pas encore.
  • Notre approche est toujours respectueuse, et notre objectif n’est pas de juger, mais d’apporter des solutions.

Une fois la confiance établie, les équipes internes voient que notre but est de les aider, pas de les remplacer.

Pourquoi est-ce que les interventions subséquentes sont plus rapides et plus efficaces?

Parce que je ne pars plus de zéro et que la collaboration s’améliore avec le temps.

  • Lors de notre première visite, nous passons du temps à comprendre votre environnement et à établir une relation de confiance.
  • La deuxième fois, nous savons où chercher, et votre équipe nous fait davantage confiance, ce qui facilite l’accès aux informations.
  • Les processus et outils mis en place lors de notre première intervention permettent souvent d’accélérer le troubleshooting futur.

Chez nos clients récurrents, nous pouvons être 2 à 3 fois plus efficace qu’au premier appel, car nous avons déjà un historique et une méthode de travail efficace en place.

Quels outils et accès sont nécessaires pour une intervention efficace?

Ça varie selon la nature du problème, mais voici les éléments essentiels :

  • Si le problème concerne un poste de travail: Nous aurons besoin d’un accès à un poste qui exhibe le problème (parfois deux pour comparer les comportements).
  • Nous travaillons avec des outils reconnus dans le marché: WireShark, VSCode, Powershell, Sysinternals. Nous vous en ferons la demande selon le cas.
  • Si l’environnement peut être virtualisé C’est un atout, car ça permet de tester sans impacter la production.
  • Si le problème est réseau ou système nous aurons besoin d’un accès aux logs, aux configurations et aux outils de monitoring (si disponibles).
  • Accès à distance (VPN, RDP, Jumpstation, etc.) dans certains cas, un accès sécurisé à distance permet d’analyser sans être sur site.
  • Collaboration avec un interne Parfois, nous devons travailler en partenariat avec un membre de votre équipe IT, notamment lorsque l’accès aux infrastructures est restreint.

Plus nous avons accès aux bons outils, plus le diagnostic sera rapide et efficace.

Conservez-vous des données de l’entreprise après une intervention?

Non, d'ailleurs, dans plusieurs cas, l'intervention commence par la signature d'une entente de confidentialité avec nos clients. Nous ne conservons pas de données, sauf des notes de documentation si cela est permis et utile pour les interventions futures.

  • Notre rôle est de diagnostiquer et résoudre les problèmes, pas d’archiver des informations sensibles.
  • Lorsqu’un client le permet, nous documentons les interventions pour accélérer le troubleshooting lors d’appels futurs.

Vous gardez le contrôle total sur vos données, et nous respectons toutes les règles de confidentialité en place.

Conservez-vous des données de l’entreprise après une intervention?

Non, d'ailleurs, dans plusieurs cas, l'intervention commence par la signature d'une entente de confidentialité avec nos clients. Nous ne conservons pas de données, sauf des notes de documentation si cela est permis et utile pour les interventions futures.

  • Notre rôle est de diagnostiquer et résoudre les problèmes, pas d’archiver des informations sensibles.
  • Lorsqu’un client le permet, nous documentons les interventions pour accélérer le troubleshooting lors d’appels futurs.

Vous gardez le contrôle total sur vos données, et nous respectons toutes les règles de confidentialité en place.

Pourquoi devons-nous vous fournir un poste ou un accès à distance pour diagnostiquer le problème?

Parce que chaque problème doit être étudié dans son contexte réel. Toutefois, il nous arrive de travailler à distance (via Teams par exemple) lorsque le contexte ne le permet absoluement pas pour des raisons de sécurité. Mais pour des problèmes complexes, de longue haleine, ça peut-être contraignant

  • Sans un accès direct au poste ou à l’environnement problématique, nous pouvons seulement poser des hypothèses basées sur les symptômes rapportés.
  • Un test sur une machine saine ne permet pas toujours de reproduire un problème intermittent ou spécifique à un environnement donné.

L’accès direct nous permet de voir ce qui se passe en temps réel et de tester différentes hypothèses beaucoup plus rapidement qu'a travers une autre personne sous formes de "commandes verbales".

Est-ce que le travail est admissible aux crédits fédéraux de Recherche Scientifique et Développement expérimental

Si vous avez besoin d'informations relatives à la création de formulaire T661, merci de nous en informer dès le début des travaux.

Vous avez un problème insoluble? Mettons-y fin dès aujourd’hui.

Discutons ensemble et voyons comment rétablir votre productivité rapidement.
Planifiez une consultation gratuite dès maintenant!
Items have been added to cart.
One or more items could not be added to cart due to certain restrictions.
- Added to cart
- Can't add this product to the cart now. Please try again later.
- Quantity updated
- An error occurred. Please try again later.
Deleted from cart
- Can't delete this product from the cart at the moment. Please try again later.