Le document traite des compétences nécessaires pour la transition numérique dans l'économie numérique, ou 'iconomie', soulignant l'importance de l'évolution des métiers de l'IT face aux nouvelles technologies et méthodologies, telles que l'open source, l'agile et le cloud. Il met en avant le rôle des jeunes comme catalyseurs du changement, tout en abordant la nécessité de gérer la 'dette technique' à travers une approche d'urbanisme des systèmes d'information et une gouvernance adaptée. Enfin, il suggère des solutions pratiques pour réduire cette dette technique et éviter que celle-ci ne s'accroisse.

1. 1
Quelles compétences
pour la transition
numérique ?
03 JUIN
AMPHITHÉÂTRE RICHELIEU
Sorbonne
Evolutions des besoins en compétences IT dans l’iconomie
Exposé de René Mandel dans le cadre de la table ronde
Les compétences dont aura besoin l’économie numérique, dénommée l’iconomie, résultent d’une double
évolution, rapide et durable :
• Du côté des métiers de l’IT, un chamboulement technologique avec de nouvelles solutions qui
chalengent les traditionnelles, en particulier avec l’émergence à un stade industriel du monde de
l’open source,
• Du côté du business lui-même, avec l’invasion de l’IT dans toutes les faces des modèles, et, par
voie de conséquence, dans tous les métiers.
Le Club Urba-EA, réunissant les architectes d’entreprise et les urbanistes de systèmes d’information est à
la charnière de ces 2 évolutions.
Il est clair que la place des « jeunes » comme acteurs du changement dans ces 2 révolutions sera
déterminante, que ce soit au sein des grands comptes ou dans les DSI, voire avec les start-up dont le
rythme de création est impressionnant.
Revenons sur les 2 révolutions :

2. 2
Les métiers de l’IT
Après plusieurs années de stabilité, de nettes ruptures sont apparues :
• Concernant les projets de développement, avec les méthodes « agiles », le rapprochement du
développement et de la « production » (DevOps),
• Concernant la modélisation des données avec le monde NoSql et diverses formes de
structuration alternatives ou complémentaires au modèle relationnel (bases de données
orientées colonnes, bases orientées document, « search », données immuables, …),
• Concernant les infrastructures avec le monde Hadoop,
• Concernant les data center avec les offres Cloud qui cassent les prix et les carcans.
Ce rythme d’innovations est dû au processus Darwinien qui s’est mis en route dans l’écosystème de ces
solutions,,, majoritairement open source, et industrialisées au sein des Gafa. Il est clair que ce rythme est
très rapide et s’est accéléré depuis la création d’internet.
Ce bouleversement ne signifie pas que tout le savoir-faire traditionnel est devenu inutile. Par exemple, sur
le cœur du SI, sur son noyau le plus stable, au-delà des besoins éphémères, l’exigence de modélisation
demeure. Simplement la coexistence entre plusieurs cultures, depuis la conception jusqu’à la réalisation
et l’opération, crée une complexité supplémentaire.
En outre les pratiques traditionnelles ne peuvent évoluer rapidement, car elles sont encadrées par des
méthodologies lourdes, conçues bien avant cette révolution technologique, dans une époque où les
interfaces étaient figés, les échanges applicatifs majoritairement par lots, … Cette inertie est renforcée par
les pratiques de référencement, de certification, par exemple dans le domaine de l’Enterprise
Architecture qui est un marché de consulting international, ou dans celui de la modélisation des SI, ou de
l’optimisation des processus…
Dans ce contexte, les « anciens », au vu des accélérations actuelles, sont souvent perplexes, dubitatifs,
dépressifs… et n’acceptent pas naturellement la remise en cause d’une partie de leur savoir-faire. Le
changement passe par les « jeunes » qui n’ont pas à s’embarrasser des anciennes pratiques.

3. 2
Les métiers de l’IT
Après plusieurs années de stabilité, de nettes ruptures sont apparues :
• Concernant les projets de développement, avec les méthodes « agiles », le rapprochement du
développement et de la « production » (DevOps),
• Concernant la modélisation des données avec le monde NoSql et diverses formes de
structuration alternatives ou complémentaires au modèle relationnel (bases de données
orientées colonnes, bases orientées document, « search », données immuables, …),
• Concernant les infrastructures avec le monde Hadoop,
• Concernant les data center avec les offres Cloud qui cassent les prix et les carcans.
Ce rythme d’innovations est dû au processus Darwinien qui s’est mis en route dans l’écosystème de ces
solutions,,, majoritairement open source, et industrialisées au sein des Gafa. Il est clair que ce rythme est
très rapide et s’est accéléré depuis la création d’internet.
Ce bouleversement ne signifie pas que tout le savoir-faire traditionnel est devenu inutile. Par exemple, sur
le cœur du SI, sur son noyau le plus stable, au-delà des besoins éphémères, l’exigence de modélisation
demeure. Simplement la coexistence entre plusieurs cultures, depuis la conception jusqu’à la réalisation
et l’opération, crée une complexité supplémentaire.
En outre les pratiques traditionnelles ne peuvent évoluer rapidement, car elles sont encadrées par des
méthodologies lourdes, conçues bien avant cette révolution technologique, dans une époque où les
interfaces étaient figés, les échanges applicatifs majoritairement par lots, … Cette inertie est renforcée par
les pratiques de référencement, de certification, par exemple dans le domaine de l’Enterprise
Architecture qui est un marché de consulting international, ou dans celui de la modélisation des SI, ou de
l’optimisation des processus…
Dans ce contexte, les « anciens », au vu des accélérations actuelles, sont souvent perplexes, dubitatifs,
dépressifs… et n’acceptent pas naturellement la remise en cause d’une partie de leur savoir-faire. Le
changement passe par les « jeunes » qui n’ont pas à s’embarrasser des anciennes pratiques.

4. 4
Question : Comment régler
le problème de la
« dette technique » ?
On peut :
• D’une part progressivement réduire la dette technique
• D’autre part éviter qu’elle ne s’accroisse.
Réduire la dette technique
La dette technique est due :
• A un empilement applicatif et d’architectures
• A des incohérences sur les informations communes et transverses
• A, toutes choses étant égales par ailleurs, à une complexification « naturelle » du SI
Les travaux de réduction de la dette technique relèvent donc d’une approche d’urbanisme des SI, sans
qu’il ne soit forcément nécessaire de faire un big bang, ou de recourir à des méthodologies lourdes. On
peut s’inspire de la « Trame des Activités d’EA (voir : http://www.urba-ea.org/)
On pourra par exemple mettre en place une gestion du patrimoine applicatif (voir : http://www.it-
expertise.com/les-cles-de-la-gestion-du-patrimoine-applicatif-decider-et-agir/).
Pour les données, l’approche classique et outillée : le Master Data Management (voir : http://www.it-
expertise.com/a-a-partager-le-master-data-management-au-service-de-lorganisation/).
On peut aussi réduire progressivement les incohérences et l’asynchronisme entre les « silos » applicatif,
par la mise en œuvre de « puits de données » (voir : http://www.value-architecture.com/2014/03/a-la-
decouverte-des-puits-de-donnees.html et http://fr.slideshare.net/RenMANDEL/principe-du-puits).
Toutes ces approches sont complémentaires.
En ce qui concerne la complexification du SI, la solution habituelle est de lutter contre cette dérive par
une gouvernance, car le sujet ne résulte pas exclusivement des choix applicatifs ou techniques. Il faut
aussi être conscient du fait qu’il y a une complexification « naturelle » du SI, qui échappe en partie à la
gouvernance, mais ceci est un sujet de recherche (voir : http://fr.slideshare.net/RenMANDEL/focus-
composants).

5. 5
Eviter que la dette technique ne s’accroisse
On retrouve ici les activités d’un architecte d’entreprise, en particulier sa participation aux projets.
L’évolution du patrimoine doit être facilitée, pour éviter un cloisonnement entre silos, et entre anciens et
nouveaux systèmes. Il doit être possible de supprimer progressivement d’anciens composants (nécrose),
et d’insérer en douceur de nouveaux composants (couveuse), grâce à une « architecture agile » (voir par
exemple le principe des composants « Janus » : http://fr.slideshare.net/RenMANDEL/urba-ea-
topopuitsv4extrait)
René MANDEL le 8/6/2015