Présentation
Dans les organisations soumises à des exigences de confidentialité, les documents portent une étiquette de sensibilité (Microsoft Information Protection). Mais lorsqu'un utilisateur imprime un tel document vers une imprimante PDF virtuelle, le fichier produit perd cette étiquette : le PDF obtenu peut alors circuler librement, sans contrôle. SNCDetector a été développé pour fermer cette brèche.
Installés dans Word, Excel et PowerPoint, les compléments détectent qu'un document classifié est sur le point d'être imprimé en PDF et redirigent l'opération vers l'export PDF natif d'Office, qui, lui, conserve les métadonnées et le niveau de confidentialité. L'utilisateur garde la main, mais la classification n'est jamais perdue par accident.
Architecture
La suite est conçue autour du patron Template Method. Une classe de base abstraite porte toute la logique commune — détection, lecture de l'étiquette, dialogue avec l'utilisateur, journalisation — et définit les quelques points où le comportement diffère d'une application à l'autre. Trois compléments concrets, un par application Office, ne font qu'implémenter ces points spécifiques. L'essentiel du code n'est écrit qu'une seule fois.
Chaque complément est un add-in VSTO qui s'accroche aux événements d'impression d'Office au démarrage de l'application hôte. La difficulté n'est pas tant la détection que la diversité des modèles d'événements : Word, Excel et PowerPoint n'exposent pas les mêmes points d'accroche ni les mêmes possibilités d'annulation. Une part notable de la conception consiste à absorber ces différences sans dupliquer la logique métier.
Le comportement est entièrement paramétrable via la base de registre — mode silencieux ou interactif, journalisation, listes d'imprimantes — avec des valeurs par défaut créées au premier lancement. L'ensemble est couvert par 125 tests unitaires NUnit qui valident la matrice de décision et la lecture de configuration, indépendamment d'Office.
Décisions techniques
Écrire la logique une seule fois. Plutôt que trois compléments indépendants, toute la logique de détection a été isolée dans une classe de base partagée. Chaque application Office n'apporte que ses spécificités. Résultat : une correction de comportement profite immédiatement aux trois compléments, et la prise en charge d'une nouvelle application se réduirait à quelques méthodes.
Composer avec les contraintes de chaque hôte. PowerPoint, en particulier, n'offre pas de moyen propre d'annuler une impression : son modèle d'événements est plus pauvre que celui de Word ou d'Excel. La solution n'a pas été de contourner le problème mais d'adapter l'expérience — informer l'utilisateur au bon moment et neutraliser les effets de bord d'un déclenchement en cascade. Chaque application est traitée selon ce qu'elle permet réellement, pas selon un modèle idéal.
Rendre testable un code couplé à Office. Un add-in VSTO dépend d'objets COM d'Office, impossibles à instancier dans un test. La logique de décision a donc été extraite de toute dépendance à Office et confiée à la classe de base, ce qui a permis de la couvrir par 125 tests automatisés via une implémentation de test dédiée. La partie réellement liée à Office reste mince et vérifiée manuellement.