Devenir architecte de systèmes d'information : le chemin, les compétences, les pièges

On devient rarement architecte par nomination. On le devient parce qu'à un moment, on a cessé de se demander comment coder une fonction pour se demander ce qui arrivera au système dans cinq ans si on la code ainsi.

Ce que fait réellement un architecte

Trois responsabilités reviennent dans toutes les missions.

• Décider des structures difficiles à changer. Le découpage en applications, le choix des formats d'échange, l'endroit où vit la donnée de référence. Ce qui coûte cher à modifier plus tard mérite d'être décidé lentement.
• Rendre les choix explicables. Un choix d'architecture que le commanditaire ne comprend pas ne sera pas défendu quand il coûtera. L'architecte passe beaucoup de temps à expliquer, en langage métier, pourquoi telle option.
• Tenir la cohérence dans la durée. Les équipes changent, les urgences passent, les exceptions s'accumulent. Le rôle consiste à savoir lesquelles sont acceptables.

Le chemin

Partir du développement. Un architecte qui n'a jamais exploité ce qu'il a conçu produit des schémas élégants et impraticables. Cinq à sept ans de développement sérieux, dont au moins un projet mené jusqu'à la mise en production et son exploitation, constituent la base.

Passer par l'exploitation. Rien n'enseigne mieux la conception qu'une astreinte. On y apprend ce qu'est un journal illisible, une sauvegarde non testée, une dépendance qui tombe le vendredi soir.

Apprendre le métier du client. C'est la marche la plus haute, et celle qu'on saute le plus souvent. Comprendre comment se monte un budget public, comment circule un dossier de prestation, pourquoi un contrôle existe : c'est cela qui distingue une architecture qui sert d'une architecture qui impressionne.

Apprendre à écrire. Une note de cadrage claire de quatre pages a plus d'effet qu'un schéma de trente boîtes. Les architectes qui progressent sont ceux dont les écrits circulent.

Les compétences à construire

• Modélisation des données. Si la donnée de référence est mal définie, aucune couche applicative ne rattrapera le problème.
• Intégration et interfaces. L'essentiel de la complexité d'un système d'information institutionnel n'est pas dans les applications, il est entre elles.
• Sécurité et conformité. Savoir où passe une donnée personnelle, qui y accède, combien de temps on la conserve.
• Coût total de possession. Une solution se juge sur ce qu'elle coûtera à exploiter et à faire évoluer, pas sur son prix d'acquisition.
• Négociation. Une architecture est toujours un arbitrage entre des exigences contradictoires portées par des personnes différentes.

Les certifications — TOGAF pour l'architecture d'entreprise, les certifications d'éditeurs cloud pour l'infrastructure — ont leur utilité : elles donnent un vocabulaire commun et rassurent dans les appels d'offres. Elles ne remplacent pas l'expérience d'un système qu'on a vu vieillir.

Les pièges

L'architecte hors-sol. Celui qui produit des documents que personne ne lit, parce qu'il a cessé de toucher au système. Le remède est simple et impopulaire : rester impliqué dans des tâches réelles, revoir du code, participer aux mises en production.

La sur-conception. Prévoir une charge qui n'arrivera jamais, découper en services une application que trois personnes utiliseront. Une architecture trop riche coûte à l'exploitation tous les jours, pour un besoin hypothétique.

Le dogme technologique. Choisir un outil parce qu'il est en vogue plutôt que parce que l'équipe saura l'exploiter. Dans nos contextes, la question « qui maintiendra cela dans deux ans, et est-ce que cette compétence existe à Dakar ? » tranche plus de débats que n'importe quel comparatif.

Un premier pas concret

Si vous visez ce métier, commencez par documenter l'architecture du système sur lequel vous travaillez aujourd'hui : les composants, les flux, les données de référence, les décisions passées et leurs raisons. Faites-le relire par plus expérimenté que vous. Vous apprendrez davantage dans cet exercice que dans trois formations.