Generix nomme Jimmy Anidjar Président non exécutif du Conseil d’administration Lire le communiqué de presse
Points essentiels à retenir
En AS2 et OFTP2, identifiez les certificats X.509 par usage : signature, chiffrement, authentification ou protection de session. En SFTP, inventoriez les objets SSH, sans leur appliquer automatiquement les règles X.509. Un raccordement peut dépendre de plusieurs objets dont les échéances diffèrent.
Un certificat AS2 est un certificat X.509 associant une identité à une clé publique utilisée pour sécuriser les messages. La clé privée locale sert à signer ou à déchiffrer ; le certificat public du partenaire permet de vérifier sa signature ou de chiffrer à son intention. La RFC 4130, publiée en juillet 2005, décrit AS2 sur HTTP, la sécurité des messages et les acquittements MDN. Le certificat HTTPS protège, lui, la session TLS. (rfc-editor.org)
OFTP2 distingue également sécurité de session et sécurité des fichiers, dans la RFC 5024 de novembre 2007. Pour l’exploitation actuelle, la notice Odette OP08, version 3.2 de mars 2026, mentionne les certificats et l’échange de données partenaires XML. Cette version reste la plus récente retrouvée en octobre 2026 ; la notice ne permet pas d’en déduire les procédures détaillées. (rfc-editor.org)
Pour distinguer transport et contenu, consultez notre guide des formats et normes EDI.
SFTP utilise SSH. La clé utilisateur authentifie le compte ; la clé d’hôte identifie le serveur. OpenSSH utilise notamment authorized_keys pour les autorisations utilisateur et known_hosts pour la confiance envers les hôtes. Il prend aussi en charge des certificats SSH signés par une autorité : ce ne sont pas des certificats X.509.
Une clé publique brute n’a pas d’expiration X.509 intrinsèque : fixez une échéance organisationnelle de rotation. Un certificat SSH peut comporter une période de validité, comme le décrit le manuel OpenSSH ssh-keygen, consulté en octobre 2026.
Un inventaire exploitable relie chaque objet cryptographique à un partenaire, un usage, un environnement et un responsable. Il doit permettre de savoir qui modifiera quoi et qui confirmera le résultat. Il est recommandé de le tenir dans un référentiel partagé, sans clé privée ni secret.
Créez une fiche par association entre objet, connexion et usage. Un même certificat partagé entre plusieurs partenaires doit rester identifiable comme dépendance commune. Renseignez les champs suivants :
Une empreinte est un condensat calculé sur un objet pour identifier précisément sa version. Utilisez-la comme référence de rapprochement, puis faites-la confirmer par un canal authentifié déjà établi. Le simple nom du fichier ne constitue pas une preuve suffisante.
Archivez la confirmation d’importation, l’environnement testé, les identifiants des échanges et le résultat métier. Generix recommande de distinguer « envoyé », « importé », « testé » et « activé » : ces états ne sont pas interchangeables. Le référentiel conserve uniquement les références vers les emplacements sécurisés des secrets.
Le propriétaire du raccordement pilote le renouvellement, même lorsqu’un prestataire exécute les opérations. Affectez un responsable final par action et obtenez l’engagement du partenaire sur ses propres tâches. Le calendrier indicatif part de l’expiration, mais prévoit une bascule effective suffisamment en amont.
Les jalons suivants sont une proposition rédactionnelle, sans valeur réglementaire ni statistique. J désigne l’expiration du certificat, ou l’échéance de rotation retenue pour une clé :
Ajustez ces délais à la durée réelle du certificat, aux contrats et aux contraintes partenaires. La bascule intervient avant J, avec une marge pour corriger un échec. Generix recommande d’identifier les périodes logistiques sensibles avant de réserver cette fenêtre.
Cette matrice RACI est à contractualiser : R réalise, A assume la responsabilité finale, C est consulté et I est informé. Une case A/R cumule pilotage et réalisation ; chaque ligne comporte un seul A.
| Action | DSI / intégration | RSSI / PKI | Exploitation ou prestataire | Partenaire | Métier / ADV |
|---|---|---|---|---|---|
| Inventorier et planifier | A | C | R | C | C |
| Valider le nouvel objet et sa protection | C | A | R | C | I |
| Prévenir et collecter les confirmations | A | I | R | R | I |
| Importer et tester côté partenaire | C | C | C | A/R | I |
| Autoriser la bascule locale | A | C | R | C | C |
| Valider le résultat métier | C | I | R | C | A |
| Surveiller et coordonner la reprise | A | C | R | R | C |
Le chevauchement est une période durant laquelle ancien et nouvel objets sont acceptés pour les usages prévus. Il facilite une transition progressive, mais dépend des logiciels et des configurations. Ne confondez jamais importation du nouveau certificat, acceptation en entrée et activation en sortie.
La documentation de rotation AS2 d’AWS Transfer Family, consultée en octobre 2026, décrit plusieurs certificats par profil et des dates d’activité. Cet exemple ne garantit pas une capacité équivalente ailleurs : vérifiez chaque usage sur les logiciels effectivement déployés.
En OFTP2, des mécanismes automatisés existent. Odette décrit l’échange de données partenaires PDX XML et de certificats, avec des niveaux de prise en charge différents selon les solutions, vérifiés en octobre 2026. Confirmez leur activation et leur interopérabilité avant de compter sur eux. (odette.org)
Generix recommande une procédure consignée dans le dossier de changement :
Le go/no-go dépend des confirmations et des résultats : sans confirmation requise ou avec un test critique en échec, ne basculez pas. Si la double acceptation est impossible, préparez une fenêtre synchronisée, la suspension maîtrisée des émissions concernées, leur mise en attente puis leur reprise. N’annoncez pas une absence de coupure que cette configuration ne permet pas de garantir.
Ne retirez l’ancien objet des usages actifs qu’après validation des flux prévus. Un retour arrière exige qu’il reste valide, non révoqué, non compromis et encore accepté par les parties concernées. Sinon, déclenchez la procédure de continuité et de reprise.
Distinguez retrait d’usage et conservation sécurisée des clés nécessaires au déchiffrement des messages en attente. En SFTP, traitez séparément clé utilisateur et clé d’hôte. Le mécanisme OpenSSH UpdateHostKeys peut accompagner la rotation des clés d’hôte sous conditions de confiance et de compatibilité ; ne désactivez jamais le contrôle d’identité du serveur pour contourner une alerte.
Un flux silencieux est un échange attendu qui n’arrive plus, sans erreur nécessairement visible. Détectez-le en rapprochant dernier succès, fenêtre attendue et calendrier métier. Cette approche distingue la disponibilité technique du raccordement et l’arrivée effective des commandes ou avis d’expédition.
La documentation AWS de surveillance des certificats, consultée en octobre 2026, propose des alertes à 30, 14 et 7 jours avant échéance. Ce sont ses exemples, pas une norme. Sa métrique DaysUntilExpiry repose sur InactiveDate : elle ne doit pas être confondue avec NotAfter, la fin de validité X.509.
Complétez les alertes d’échéance par des règles sur les erreurs de signature, de déchiffrement et d’authentification, les acquittements manquants, l’âge des messages et la croissance des files. Generix recommande de distinguer connexion réussie, transfert réussi et traitement métier confirmé.
Un MDN AS2 est un acquittement technique du message AS2, positif ou négatif selon son statut. Même positif, il ne prouve pas l’intégration de la commande dans l’ERP. Corrélez-le avec les statuts applicatifs et l’objet métier attendu.
Pour chaque flux critique, définissez le dernier succès, la fenêtre normale d’arrivée, les jours ouvrés, les exceptions et le propriétaire de l’alerte. Contractualisez les seuils : un flux irrégulier ne se surveille pas comme un échange quotidien.
À l’alerte, vérifiez la production du message chez l’émetteur, son transport puis son intégration. Prévenez le partenaire et le métier, estimez les commandes ou expéditions concernées et encadrez les reprises pour éviter les doublons.
Le bon modèle dépend des compétences disponibles, des engagements contractuels et de la criticité des échanges. Exploitation interne, plateforme spécialisée indépendante et réseau B2B intégré sont des options légitimes. Generix privilégie une lecture collaborative : coordonner partenaires et exécution logistique, plutôt que vérifier seulement le raccordement local.
Examinez les options selon le partage réel des responsabilités :
Pour cadrer l’architecture, notre comparatif EDI, Web EDI et API complète cette analyse. Aucun modèle ne dispense d’une confirmation du partenaire.
Pour Generix, l’enjeu est de relier le suivi des échanges aux événements attendus dans le WMS, le TMS ou l’OMS. Vérifiez qu’une commande atteint sa destination, qu’un ASN/DESADV prépare la réception et qu’une reprise ne déclenche pas deux traitements. Une suite intégrée peut simplifier cette coordination ; une architecture multiacteur reste possible si ses responsabilités sont explicites.
Cette approche n’attribue à nos solutions ni rotation automatique ni prise en charge universelle du double certificat : ces capacités doivent être vérifiées sur votre périmètre.
Préparez votre revue d’exploitation avec nos équipes : inventaire des certificats et clés, partenaires à prévenir, scénarios de test et supervision. Découvrez notre logiciel EDI Generix, puis contactez un expert pour examiner votre périmètre et le partage des responsabilités.
En résumé
Inventoriez les usages, prévenez les partenaires, préchargez le nouveau certificat et obtenez leur confirmation. Testez les échanges dans les deux sens, puis activez les usages sortants et surveillez avant de retirer l’ancien objet. La coexistence dépend des logiciels : elle n’est pas une garantie universelle de continuité.
Oui, lorsque la plateforme le permet, mais accepter plusieurs certificats entrants ne signifie pas les utiliser simultanément en sortie. AWS Transfer Family documente plusieurs certificats par profil et des dates d’activité qui encadrent leur utilisation. Vérifiez séparément les règles de signature, de chiffrement et de sélection sortante sur votre logiciel.
Cette responsabilité peut être attribuée au propriétaire du raccordement ou à son prestataire si le contrat le prévoit. Generix recommande de désigner explicitement l’interlocuteur chargé de relancer les partenaires et de collecter les confirmations d’importation et de test. Cette organisation relève de la gouvernance d’exploitation, pas d’une obligation générale imposée par le protocole.
Le certificat AS2 intervient dans la signature ou le chiffrement des messages ; le certificat HTTPS contribue à sécuriser la session TLS. Ces protections agissent à des niveaux distincts. Même lorsqu’un déploiement réutilise un certificat, inventoriez séparément les usages et les dépendances.
Oui, des mécanismes d’échange automatisé existent, notamment autour des données partenaires PDX XML décrites par Odette. Leur prise en charge varie selon les logiciels, avec des capacités d’émission, de réception ou une absence de support. Vérifiez l’activation, les contrôles de confiance et l’interopérabilité avant de vous appuyer sur cette automatisation.
Pas nécessairement : SFTP utilise SSH, avec notamment des clés utilisateur, des clés d’hôte ou des certificats SSH. Une clé publique brute n’a pas de date d’expiration X.509 intrinsèque ; prévoyez une échéance organisationnelle de rotation. Si vous utilisez un certificat SSH, contrôlez aussi sa période de validité.
Non : un MDN renseigne le traitement technique AS2, pas l’intégration métier complète. Vérifiez son statut, puis rapprochez l’identifiant du message des contrôles applicatifs et de la commande attendue. La validation finale doit porter sur l’objet effectivement présent dans l’ERP, le WMS ou l’OMS.
Définissez une alerte d’absence à partir du dernier échange réussi, de la fenêtre attendue et de la criticité du flux. Intégrez les jours non ouvrés, la saisonnalité et les échanges irréguliers, sans seuil universel. À l’alerte, contrôlez successivement l’émission chez le partenaire, le transport et l’intégration métier.
Convertissez vos volumes en heures de travail, affectez les compétences et réservez les moyens disponibles. Quatre gabarits copiables et un comparatif des outils vous guident du planning hebdomadaire aux réaffectations horaires.
Préparez votre migration EDI vers le SaaS : inventaire des flux, reprise des mappings, tests en miroir et bascule par vagues. Définissez les preuves de recette et le retour arrière avec vos partenaires.
Travaillez avec nos équipes pour concevoir et mettre en œuvre la Supply Chain qui accompagnera votre croissance, adaptée à vos spécificités métier.
