Il y a un moment dans la vie d’un intégrateur logiciel où il finit par adopter un réflexe pavlovien.
Quelqu’un demande :
— « Tu fais quoi dans la vie ? »
Tu réponds :
— « Je suis intégrateur logiciel. »
Et là, tu vois le regard qui hésite entre trois cases :
- « Ah, donc tu fais du HTML/CSS ? »
- « Ah, donc tu installes des imprimantes ? »
- « Ah, donc tu es développeur… mais tu n’oses pas le dire ? »
Et comme tu n’as pas envie de passer la soirée à dessiner des flèches entre des boîtes imaginaires sur une nappe en papier, tu réponds souvent un truc du style :
— « Je fais en sorte que les logiciels arrêtent de se détester. »
Cet article, c’est la version longue de cette phrase. Avec un peu de pédagogie, un peu de vécu, et un tout petit coup de gueule (sinon, ce n’est pas drôle).
1) “Intégrateur” : de quoi parle-t-on, exactement ?
Le premier piège, c’est le mot.
En France, “intégrateur” peut désigner des métiers très différents. Exemple typique : l’intégrateur web, celui qui traduit une maquette en pages web, gère le responsive, l’accessibilité, etc. C’est un vrai métier, utile, et très technique… mais ce n’est pas le sujet ici.
L’intégrateur logiciel, lui, joue plutôt dans la cour du système d’information : applications métiers, progiciels, flux de données, environnements, déploiements, interfaces, recette, mise en production… bref, tout ce qui fait qu’une entreprise ne se retrouve pas avec 12 outils brillants… incapables de se parler.
Et si on veut le dire proprement, l’intégration (au sens SI) c’est l’idée de rassembler des sous-systèmes pour qu’ils fonctionnent comme un tout, en échangeant des données de façon cohérente.
Dit autrement :
- Un logiciel seul, c’est une pièce.
- Deux logiciels qui communiquent, c’est déjà une maison.
- Dix logiciels qui communiquent correctement, c’est une ville.
- Dix logiciels qui communiquent mal, c’est un embouteillage permanent… mais en version Excel + mails + “tu peux me renvoyer le fichier stp ?”.
2) Ce que fait vraiment un intégrateur logiciel (la version terrain)
On entend parfois :
« Oui bon, l’intégration, c’est surtout installer et paramétrer, non ? »
Alors… parfois oui.
Mais “installer et paramétrer”, c’est comme dire que construire un pont, c’est “poser des morceaux de métal”.
Dans beaucoup de contextes (progiciel, ERP, application métier), le cœur du métier, c’est de délivrer une version stable du produit, adaptée au besoin client, en passant par l’installation, le paramétrage, les tests (unitaires + intégration), la doc, et la prise en compte des exigences terrain.
Et dans les faits, ça ressemble souvent à un mélange de :
- Assembler : modules, connecteurs, APIs, drivers, middleware, jobs, scripts…
- Traduire : besoin métier ↔ possibilités du produit ↔ contraintes techniques.
- Sécuriser : droits, environnements, configuration, reprise de données, sauvegardes.
- Tester : pas “un test vite fait”, mais des scénarios réalistes, tordus, et parfois franchement cruels.
- Déployer : la mise en production, cette cérémonie où tout le monde te parle uniquement quand ça ne marche pas.
- Documenter : parce que sinon, dans 6 mois, même toi tu ne comprendras plus pourquoi “ce champ-là” part dans “cette table-là” via “ce mapping-là”.
Et oui : on fait aussi du support. Parce que l’intégration, ce n’est pas “livré c’est fini”, c’est “livré, donc maintenant ça vit”.
3) Les 3 grandes familles d’intégration (pour arrêter de tout mélanger)
a) L’intégration “progiciel / ERP”
Tu prends un outil (souvent lourd, souvent puissant), tu le fais coller aux processus d’une entreprise.
Ça implique typiquement :
- paramétrage de modules,
- reprise de données,
- interfaces avec les autres applications,
- recette,
- conduite du changement (oui, parfois).
Ce rôle est souvent décrit comme un pont entre utilisateurs, maîtrise d’ouvrage et équipes techniques, avec une grosse dimension projet et organisation.
b) L’intégration “applicative / flux”
Là, tu es dans le monde des échanges :
- APIs,
- messages,
- queues,
- ETL,
- synchronisations,
- formats chelous qu’on appelle “standards” uniquement parce qu’ils existent depuis 20 ans.
Objectif : éviter la phrase maudite :
« On a deux systèmes, mais on ressaisit à la main. »
c) L’intégration “déploiement / exploitation”
Tu touches aux environnements, aux pipelines, à l’industrialisation, à tout ce qui fait que “installer” n’est pas une aventure mystique.
C’est là que l’intégrateur croise souvent des pratiques proches du DevOps (sans forcément porter l’étiquette), parce qu’au final… une intégration qui ne se déploie pas proprement, c’est une intégration qui ne tiendra pas.
4) La journée type (spoiler : ce n’est pas que “Suivant → Suivant → Terminer”)
Une journée d’intégrateur logiciel, c’est rarement linéaire. C’est plutôt une succession de mini-enquêtes.
Exemples très réalistes :
- 9h12 : “Ça marche en recette mais pas en prod.”
(Traduction : tu vas lire des logs jusqu’à voir apparaître une vérité cosmique.) - 10h03 : “Le flux a doublonné 1200 lignes.”
(Traduction : il manque une clé, ou un idempotency, ou… de la chance.) - 11h20 : “Le client veut le même comportement… mais pas tout à fait.”
(Traduction : c’est le moment où le paramétrage devient de la philosophie.) - 14h07 : “On peut ajouter un champ ? C’est juste un champ.”
(Traduction : tu viens de gagner un mapping, deux tests, une migration, et une mise à jour de documentation.) - 16h55 : “On met en prod ce soir ?”
(Traduction : tu vas dîner avec des logs.)
Et au milieu de tout ça, tu fais ce que le métier exige en permanence : relier des mondes. Le monde métier (qui veut que ça tourne) et le monde technique (qui sait pourquoi ça ne tourne pas).
5) Pourquoi ce métier est sous-coté (alors qu’il est vital)
Je vais être un peu brutal :
On remarque un intégrateur logiciel quand ça casse.
Quand ça marche, on oublie qu’il existe.
C’est un métier “invisible” par nature, parce que sa réussite ressemble à… l’absence de problème.
Mais l’intégration, c’est souvent la différence entre :
- une entreprise qui a des outils cohérents,
- et une entreprise qui a une collection d’outils + un océan de contournements.
Et les contournements, ça coûte :
- du temps,
- des erreurs,
- des tensions,
- et ce petit sentiment collectif que “l’informatique, c’est compliqué” (alors que parfois… c’est juste mal relié).
6) Les compétences qui font la différence (et non, ce n’est pas “savoir cliquer”)
a) La technique utile (celle qui revient tout le temps)
- Comprendre les données : SQL, modèles, référentiels, formats, encodages.
- Comprendre les échanges : API REST, auth, webhooks, fichiers, messages.
- Comprendre l’exploitation : environnements, configs, secrets, supervision, logs.
Pas besoin d’être “le meilleur dev de la galaxie”.
Mais il faut être assez technique pour diagnostiquer, et assez rigoureux pour sécuriser.
b) La rigueur (la vraie, pas celle des slides)
L’intégration, c’est le royaume des détails :
- un champ en trop,
- une version pas alignée,
- un script lancé au mauvais endroit,
- une configuration “presque” identique,
- un test oublié.
Et ces “petits” détails deviennent très grands en production.
c) Le relationnel (oui, c’est un métier social)
Tu parles avec :
- les métiers,
- les développeurs,
- l’exploitation,
- l’éditeur,
- le client,
- parfois le prestataire du prestataire (celui qui “a la doc”, mais qui “n’est pas dispo cette semaine”).
Savoir expliquer simplement, cadrer, reformuler, poser des questions, obtenir des réponses… c’est du cœur de métier.
7) Trois cas typiques où l’intégration dérape (et comment l’éviter)
Cas n°1 : “On a acheté l’outil, donc c’est bon”
Non.
Acheter un progiciel, c’est acheter une possibilité.
L’intégration, c’est transformer cette possibilité en usage réel.
Ce qui manque souvent :
- la reprise de données (la vraie, pas “un import Excel”),
- les interfaces,
- les droits,
- les processus,
- la recette métier.
Cas n°2 : “C’est juste une interface”
Ah, la fameuse phrase.
Une interface, c’est rarement “juste” :
- un contrat de données,
- un mapping,
- des erreurs à gérer,
- des retries,
- de la traçabilité,
- des performances,
- de la sécurité,
- une supervision.
Et surtout : une interface, c’est un engagement.
Parce qu’une fois que les métiers s’y habituent… tu ne peux plus faire marche arrière.
Cas n°3 : “On fera les tests après”
Non plus.
Faire les tests après, c’est comme vérifier les freins après l’autoroute.
Les sources “fiches métier” sont d’ailleurs très claires sur le fait que tests, validation, maintenance et documentation font partie des missions classiques.
8) Avec qui bosse l’intégrateur (et pourquoi il sert de traducteur permanent)
Dans le monde progiciel/ERP, l’intégrateur est souvent en position de charnière : côté besoins utilisateurs, côté réalisation, côté exploitation, côté éditeur.
Et c’est précisément pour ça que c’est un métier “à responsabilité” :
- si tu simplifies trop, tu trahis le besoin métier,
- si tu complexifies trop, tu fais exploser l’exploitation,
- si tu ne cadres pas, tu deviens un réceptacle à demandes floues.
Le bon intégrateur n’est pas celui qui dit “oui” à tout.
C’est celui qui dit :
« Oui, mais… voilà le coût, voilà le risque, voilà l’impact, et voilà comment on le fait proprement. »
9) Comment on devient intégrateur logiciel (sans recette magique)
Il y a plusieurs portes d’entrée :
- profil technique (admin, dev, data…) qui glisse vers l’intégration,
- profil fonctionnel (process / métier) qui se technicise,
- profil “outil” (ERP, CRM, solution métier) qui devient référent puis intégrateur.
Ce qui compte le plus, ce n’est pas “le diplôme parfait”.
C’est :
- la curiosité,
- la capacité à apprendre vite,
- la rigueur,
- et un certain goût pour… résoudre des puzzles que personne n’a envie de regarder.
10) Les évolutions possibles (et pourquoi c’est une excellente base)
L’intégration donne une vision transversale rare : tu vois les applications, les données, les usages, les contraintes d’exploitation, les process métiers.
Donc, naturellement, ça ouvre vers :
- architecte d’intégration / architecte SI,
- consultant fonctionnel expert,
- chef de projet applicatif,
- lead “delivery” / industrialisation,
- DevOps / SRE (selon la trajectoire),
- voire direction de projet (si tu aimes le pilotage).
En clair : c’est un métier qui peut être un tremplin, parce qu’il te force à comprendre “le système” plutôt qu’une seule brique.
Conclusion : l’intégrateur logiciel, c’est la colle… mais la colle intelligente
Je vais finir avec une conviction simple :
On peut avoir les meilleurs logiciels du monde,
si on ne les intègre pas correctement, on fabrique du chaos organisé.
L’intégrateur logiciel, c’est celui qui :
- relie,
- sécurise,
- stabilise,
- industrialise,
- et rend utilisable.
Et si le terme “intégrateur” est parfois flou, c’est peut-être parce que ce métier est souvent trop discret.
Alors je pose la question (rituel de fin d’article) :
- Vous connaissiez ce métier avant de le croiser ?
- Vous l’appelez comment dans votre boîte : intégrateur, consultant, paramétreur, “celui qui comprend les flux” ?
- Et c’est quoi, la pire phrase qu’on vous ait dite en projet ? (“C’est juste un champ”, “on verra en prod”, “ça marchait hier”… je prends tout.)
(Bonus) La phrase toute prête à ressortir en soirée
« Je ne fais pas “juste” installer un logiciel : je fais en sorte que vos outils se parlent, que vos données soient cohérentes, et que la mise en production ne ressemble pas à un film d’horreur. »
