🔒 Note personnelle Architecture SI REST SOAP Webservices

Architecture SI et échanges

Comprendre comment les applications d'un SI s'organisent et se parlent - le regard de l'exploitant, pas du développeur.

🔷 N-tiers 🔵 REST 🟣 SOAP 🟢 Formats 🔴 Diagnostic 🟡 Cartographie ↗ Synthèse

🏗️

N-tiers

Présentation, métier, données - où chercher.

🔵

REST

API modernes, HTTP, JSON, codes de retour.

🟣

SOAP

Applications legacy, XML, WSDL.

📄

Formats

XML, JSON, CSV - lire et comprendre.

🔍

Diagnostic

Flux cassé - méthode et réflexes.

🗺️

Cartographie

Dépendances, impacts, avant tout projet.

Architecture

L'architecture n-tiers

Le modèle en couches - comprendre où se situe chaque application du SI

Une architecture n-tiers découpe un système en couches indépendantes, chacune ayant un rôle précis. Ce modèle est la base de quasiment toutes les applications d'un SI universitaire. Savoir dans quelle couche se situe un problème oriente immédiatement le diagnostic.

🌐

Présentation

Navigateur, interface
Apache en frontal
Ce que voit l'utilisateur

⚙️

Métier

Tomcat, application Java
Règles de gestion
Traitement des données

🗄️

Données

Oracle, base de données
Stockage persistant
Port 1521

Pourquoi c'est utile au quotidien

→ L'interface ne s'affiche pas → problème couche présentation (Apache, réseau, certificat SSL)
→ L'interface s'affiche mais l'action échoue → problème couche métier (Tomcat, logs catalina.out)
→ L'application tourne mais les données sont fausses ou absentes → problème couche données (Oracle, datasource, script SQL)
→ Dans un SI universitaire, chaque application est elle-même une architecture n-tiers – elles s'empilent et s'échangent des données via des webservices.

Dans un SI universitaire Une application comme Sinchro (gestion des feuilles de temps) n'est pas isolée - elle échange avec le SI RH, le SI financier, des référentiels nationaux. Chaque échange entre deux applications traverse ce modèle de couches des deux côtés.

REST

API REST

Le standard des échanges modernes - HTTP, JSON, codes de retour

REST (Representational State Transfer) est une architecture d'API qui expose des ressources via des URLs et utilise les verbes HTTP pour agir dessus. C'est le standard des applications modernes. Tu l'as pratiqué sur ton projet de facturation électronique - ici l'angle est celui de l'exploitant : comprendre ce qui circule, interpréter ce qui plante.

Les verbes HTTP - ce qu'ils font

GETGET - lire une ressource. /api/etudiants/12345 → retourne les infos de l'étudiant
POSTPOST - créer une ressource. /api/etudiants + body JSON → crée un nouvel étudiant
PUTPUT - mettre à jour. Remplace la ressource entière
DELETEDELETE - supprimer une ressource

Les codes HTTP - ce qu'ils signifient pour l'exploitant

200 OK - tout s'est bien passé

201 Créé - ressource créée avec succès

400 Bad Request - format de la requête incorrect

401 Non authentifié - token manquant ou expiré

403 Interdit - authentifié mais pas autorisé

404 Non trouvé - URL incorrecte ou ressource absente

500 Erreur serveur - bug côté application

503 Service indisponible - Tomcat arrêté ou surchargé

Tester un endpoint REST avec curl

curl -I https://api.exemple.fr/ressource	Tester qu'un endpoint répond (headers seulement)
curl https://api.exemple.fr/ressource	Appel GET - affiche la réponse JSON brute
curl -H "Authorization: Bearer TOKEN" https://...	Appel avec token d'authentification
curl -v https://api.exemple.fr/ressource	Mode verbose - voir les headers complets, utile pour diagnostiquer

Ce qu'on oublie quand ça marche

! L'authentification – token JWT, clé API, OAuth. Quand ça casse après une rotation de secrets, c'est souvent là.
! Les timeouts – une API qui met trop longtemps à répondre → 503 ou connexion coupée côté client.
! Le certificat SSL – un certificat expiré bloque tous les appels HTTPS silencieusement.
! Le format exact des headers – Content-Type: application/json oublié → 400 Bad Request sans raison apparente.

SOAP

Services SOAP

Le protocole des applications legacy - XML strict, WSDL, toujours présent dans les SI universitaires

SOAP (Simple Object Access Protocol) est un protocole d'échange plus ancien que REST, encore très présent dans les SI universitaires et les applications nationales (AMUE, Cocktail…). Il est plus verbeux et plus rigide que REST - mais cette rigidité est aussi une garantie : le contrat d'échange est explicitement défini dans un fichier WSDL.

La structure d'un message SOAP Tout message SOAP est un document XML avec trois niveaux :

Envelope - l'enveloppe qui encapsule tout le message
Header - en-tête optionnel (authentification, métadonnées)
Body - le contenu réel : la requête ou la réponse

<soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/">
  <soap:Header>
    <!-- authentification, token... -->
  </soap:Header>
  <soap:Body>
    <getEtudiant>
      <numeroEtudiant>12345</numeroEtudiant>
    </getEtudiant>
  </soap:Body>
</soap:Envelope>

Le WSDL – le contrat du service

→ WSDL (Web Services Description Language) – le fichier qui décrit toutes les opérations disponibles et les formats attendus.
→ C'est la première référence quand un flux SOAP casse – vérifier que le format envoyé correspond au WSDL.
→ Un changement de WSDL côté fournisseur sans mise à jour côté consommateur = flux cassé immédiatement.
→ URL type d'un WSDL : https://service.exemple.fr/monservice?wsdl

REST vs SOAP - comparaison rapide

Point	REST	SOAP
Format	JSON (principalement)	XML obligatoire
Contrat	Souple, documentation variable	WSDL strict et explicite
Verbosité	Léger	Verbeux (enveloppe XML)
Contexte	Applications modernes	Applications legacy, AMUE, SI nationaux
Diagnostic	Codes HTTP + logs	Message d'erreur XML + WSDL

Formats

Formats de données

XML, JSON, CSV - savoir les lire, comprendre ce qu'ils transportent

Les trois formats qu'on retrouve partout dans un SI universitaire. Tu les connais déjà via SEPA (XML), ton app de facturation (JSON) et DADS (fichiers plats). L'angle ici : les pièges à connaître et les réflexes quand un flux est rejeté.

XML - SEPA, PES, SOAP Structure arborescente balisée, validée par un schéma XSD. Un XML invalide est souvent rejeté silencieusement ou avec un message d'erreur peu explicite.

Pièges classiques : balise non fermée, caractère interdit non échappé (& au lieu de &), namespace manquant, encodage incorrect.

Réflexe : valider le XML contre son schéma XSD avant de chercher ailleurs. Un outil comme xmllint peut le faire en ligne de commande : xmllint --schema schema.xsd fichier.xml

JSON - API REST modernes Format léger clé/valeur, pas de schéma imposé par défaut. Plus souple que XML mais aussi moins protégé contre les erreurs de format.

Pièges classiques : virgule en trop ou manquante, guillemets absents sur une clé, type incorrect (chaîne au lieu de nombre), champ attendu absent.

Réflexe : coller le JSON dans un validateur (jsonlint.com) ou utiliser echo '...' | python3 -m json.tool pour vérifier la syntaxe.

CSV / Fichiers plats - DADS, exports, imports Format simple mais source de nombreux incidents en production.

Pièges classiques :
- Séparateur : virgule vs point-virgule vs tabulation - une application attend l'un, reçoit l'autre
- Encodage : UTF-8 vs ISO-8859-1 → les accents français deviennent des caractères illisibles
- Retours à la ligne : Windows (CRLF) vs Linux (LF) → peut faire planter le parsing
- En-tête : certaines applications attendent une ligne d'en-tête, d'autres non

Réflexe : file fichier.csv pour voir l'encodage, cat -A fichier.csv | head -3 pour voir les fins de ligne (^M = CRLF Windows).

Le piège universel - l'encodage des caractères

!Un fichier produit sous Windows en ISO-8859-1 traité par une application Linux en UTF-8 → les accents (é, è, à, ç) deviennent des caractères bizarres
!C'est invisible à la génération, visible seulement à la réception - difficile à diagnostiquer sans y penser
!Commande de conversion : iconv -f ISO-8859-1 -t UTF-8 fichier.csv > fichier-utf8.csv
!Concerne XML, CSV et fichiers plats - pas JSON (toujours UTF-8 par spécification)

Diagnostic

Diagnostiquer un flux cassé

Méthode et réflexes - de la question à la cause

Un flux entre deux applications ne fonctionne plus. Avant de toucher quoi que ce soit, se poser les bonnes questions dans le bon ordre évite de perdre du temps et de créer de nouveaux problèmes.

Ce flux a-t-il déjà fonctionné ?

Si oui : qu'est-ce qui a changé récemment ? Déploiement, rotation de mot de passe, changement réseau, mise à jour système. Le changement est presque toujours la cause.

Le problème est-il réseau ?

Tester que le serveur distant est joignable : ping serveur. Tester que le port répond : telnet serveur 443 ou nc -zv serveur 443. Si ça ne répond pas, le problème est réseau ou firewall - pas applicatif.

La requête arrive-t-elle au serveur ?

Vérifier les logs Apache : tail -f /var/log/apache2/access.log. Si la ligne apparaît → la requête arrive. Si elle n'apparaît pas → le problème est avant (réseau, DNS, configuration client).

Le serveur la traite-t-il correctement ?

Vérifier le code HTTP retourné dans access.log. 401/403 → authentification. 404 → URL incorrecte. 500 → erreur applicative → aller dans catalina.out.

Lire l'erreur applicative

grep -i "error\|exception" /opt/tomcat/logs/catalina.out | tail -50. Le message d'erreur indique généralement la couche concernée : datasource, format de données, règle métier.

Cas Talend - flux orchestrés

Talend produit ses propres logs de job. Identifier le job concerné, trouver son log d'exécution. Le message d'erreur Talend indique la transformation ou la connexion qui a échoué. Ne jamais relancer un job Talend en production sans comprendre pourquoi il a planté.

Les causes les plus fréquentes d'un flux cassé

1Rotation de mot de passe non répercutée sur la datasource ou la config du webservice
2Certificat SSL expiré - bloque tous les appels HTTPS sans message d'erreur explicite
3Changement de format côté fournisseur non communiqué (nouveau champ obligatoire, type modifié)
4Encodage de fichier incorrect - particulièrement sur les imports CSV/XML
5Timeout - service trop lent, connexion coupée avant la réponse
6Espace disque plein - Tomcat ne peut plus écrire, comportement imprévisible

Cartographie

Cartographier un SI

Comprendre les dépendances - indispensable avant tout projet

Dans une DSI universitaire, tu hérites d'un SI existant. Des dizaines d'applications échangent entre elles, souvent construites sur plusieurs années, parfois mal documentées. La cartographie des flux est la compétence qui distingue un responsable applicatif d'un simple technicien : savoir anticiper l'impact d'un changement avant de le faire.

Ce qu'une cartographie doit montrer Pour chaque flux entre deux applications :

Qui émet ? Quelle application produit la donnée
Qui reçoit ? Quelle application consomme
Quel format ? REST/JSON, SOAP/XML, fichier CSV, fichier plat
Quelle fréquence ? Temps réel, batch quotidien, déclenchement manuel
Quelle criticité ? Qu'est-ce qui se passe si ce flux s'arrête ?

Pourquoi les dépendances cachées sont dangereuses

! Un changement de schéma Oracle peut casser un flux Talend que personne ne savait qu'il existait.
! Une mise à jour d'une application peut modifier le format d'un webservice consommé par trois autres.
! Un renommage de colonne en base peut faire planter silencieusement un export nocturne.
! Ces incidents arrivent toujours à 6h du matin le lendemain d'une mise en production.

Les réflexes à avoir

→ Avant tout projet : demander la cartographie des flux existants impliquant les applications concernées.
→ Si elle n'existe pas : la construire – interroger les collègues, lire les configs Talend, parcourir les context.xml.
→ À chaque déploiement : identifier les applications en aval qui consomment ce qui change.
→ Documenter chaque flux découvert – la cartographie se construit progressivement, elle ne sort pas d'un seul coup.

Dans le contexte de l'université Les applications citées dans la fiche de poste - OmekaS, Conventions, Sinchro - ne sont pas isolées. Elles s'intègrent avec le SI RH, le SI financier, des référentiels nationaux, parfois via l'AMUE. Comprendre ces connexions dès les premières semaines est un vrai avantage.

Le regard de l'exploitant

Quand un flux casse : réseau d'abord (ping, telnet), puis logs Apache (la requête arrive-t-elle ?), puis Tomcat (est-elle traitée ?), puis format des données. Dans cet ordre.

Les causes les plus fréquentes ne sont pas techniques - ce sont des mots de passe qui ont changé, des certificats expirés, des formats qui ont évolué silencieusement.

La cartographie n'est pas un livrable ponctuel - c'est une connaissance qui se construit en poste, flux après flux.

N-tiers - couches REST - HTTP et JSON SOAP - XML et WSDL Formats - XML JSON CSV Diagnostic - méthode Cartographie - dépendances