Antoine PASCAL nous explique son rôle de codeur en MarTech

Tout le monde veut “faire parler la Donnée Clients”. Mais tant que la tech ne suit pas, les belles promesses du CRM, de reporting et d’IA restent au stade de l’intention. Et c’est exactement là qu’intervient Antoine Pascal.

Consultant IT orienté développement, Antoine travaille avec CustUp sur des projets où il faut faire tenir ensemble la data, le CRM et les usages métiers. Son terrain de jeu : les bases de données, les flux, le reporting, avec une bonne dose de C#, de SQL, de Power BI… et de plus en plus d’IA.

Antoine Pascal

Dans cette interview, il raconte son parcours, sa façon d’aborder les projets MarTech et ce que change l’arrivée du “vibe-coding” dans son quotidien de développeur. Vous découvrirez notamment comment il :

  • Construit des bases de données et des flux pour rendre la data réellement exploitable par les équipes métiers.
  • Dépasse les limites des outils CRM standards grâce à un développement sur-mesure.
  • S’intègre dans une équipe MarTech pour donner corps aux recommandations CRM et Datas Clients.
  • Applique quelques bonnes pratiques tech simples (qui évitent bien des frictions dans les projets).
  • Utilise l’IA pour gagner du temps… sans jamais lui déléguer totalement le pilotage de ses développements.

Si tu devais résumer ton parcours professionnel en quelques mots, tu dirais…

Je dirais que mon parcours est assez court, mais déjà très concret. J’ai commencé en alternance dans une petite structure d’une quinzaine de personnes, assez proche de l’univers de CustUp : on faisait beaucoup de conseil en CRM, data et Service Client.

La société n’éditait pas de solution CRM, mais elle les intégrait et les personnalisait. C’est là que j’ai mis les mains dans le cambouis pour la première fois : développement, flux de données, automatisation, reporting

Après l’alternance, je suis resté sur le même socle technologique, mais en tant qu’indépendant. J’ai continué à travailler pour certains clients de cette même structure (dirigée par mon père), toujours autour des mêmes sujets : CRM, données, et dev.

Aujourd'hui, tu es consultant IT, axé développement. Tu veux bien nous dire quel est ton scope d’intervention ? Et sur quels types de problématiques tu interviens ?

J’interviens principalement sur :

  • La data & le reporting :
    • Mise en place et gestion de bases de données ;
    • Structuration de l’infrastructure (sur serveur ou dans le cloud, via Azure par exemple) ;
    • Préparation de la donnée pour alimenter des reportings métiers.
  • Le développement “classique” :
    • Développement en C# et Java surtout ;
    • Mise en place de flux d’import et de transformation de données
    • Adaptation et évolution de solutions CRM existantes pour coller aux besoins métiers.
  • Les sites web, côté technique :
    • Interventions sur des sites en HTML / JavaScript ;
    • Surtout pour faire le lien entre les interfaces front et les traitements de données derrière.

En quelques mots, je suis un développeur orienté data : je fais circuler la donnée entre les systèmes, je la transforme et je la prépare pour qu’elle devienne vraiment exploitable pour les équipes métiers.

Des exemples de missions sur lesquelles tu es intervenu ?

Oui, j’en ai plusieurs en tête, que je peux regrouper en 3 groupes d’interventions.

1 - Mettre en place une base de données orientée reporting

Avec CustUp, j’interviens souvent sur des projets où le besoin client est assez simple à formuler : on veut un reporting maîtrisé, cohérent, en un seul endroit (qui ne dépend donc pas de plein d’outils différents).

Concrètement, ça donne :

  • Centraliser la donnée : je conçois et je mets en place une base de données dédiée au reporting, puis je la connecte aux différentes sources : API, dépôts de fichiers, autres outils de l’écosystème MarTech.
  • Transformer et structurer : je prépare la donnée pour qu’elle soit exploitable (structure des tables, calculs d’indicateurs, nettoyage, harmonisation).
  • Alimenter un outil de Data Vision : je branche cette base sur un outil comme Power BI, pour que les métiers aient un accès simple aux indicateurs.

2 - Aller au-delà du standard d’un CRM

Avant de travailler avec CustUp, j’intégrais une solution CRM éditée par un partenaire. Dans ce cadre, j’ai notamment :

  • Développé des envois d’emails et de SMS automatisés suivant des règles métiers spécifiques ;
  • Mis en place des extracts de données sur mesure pour alimenter d’autres outils d’analyse ou de pilotage chez les clients.

3 - Classer automatiquement les demandes clients avec l’IA

Autre type de mission : la priorisation et la qualification automatique des demandes clients. Avec un partenaire spécialisé en IA, on a connecté un modèle à la solution CRM :

  • L’IA lit le contenu de la demande entrante ;
  • Elle lui attribue une priorité ;
  • Et elle la classe selon plusieurs motifs.

Les équipes Service Client gagnent ainsi du temps, les urgences remontent mieux, et la donnée est beaucoup plus propre pour le reporting derrière.  

Qu’est-ce qui fait que “la tech” est aussi importante dès qu’on parle de Data Clients / CRM ?

Pour moi, s’il n’y a pas de tech, il ne peut pas vraiment y avoir de Données Clients. Et on ne va pas retourner à l’époque du “tout papier”. Sans systèmes, sans bases de données, sans outils, la donnée reste éparpillée, difficilement accessible, et souvent inutilisable pour piloter quoi que ce soit.

La tech sert à plusieurs choses :

  • Centraliser : regrouper les données venant de différents canaux : site web, magasin, Service Client, campagnes marketing, CRM, etc.
  • Rendre la donnée exploitable (et exploitée).
  • Aider à la décision : la tech permet par exemple de comparer la performance site vs magasin, de voir où la marge ou le volume se perdent, de cibler les segments pertinents pour des campagnes.
  • Calculer des indicateurs métiers comme :
    • le panier moyen,
    • la fréquence d’achat,
    • la valeur client dans le temps.

En résumé : la tech, ce n’est pas un “plus” sympa à avoir. C’est la condition indispensable pour que la Donnée Client existe vraiment et soit utilisable par les équipes métiers.

Peux-tu détailler quelles sont les technos adaptées en matière de bases de données ?

Sur les bases de données, j’utilise principalement SQL Server et MySQL. Ce sont les technologies incontournables pour stocker la donnée transactionnelle et marketing.

Pour gérer les flux d’import et de transformation de la data, je m’appuie beaucoup sur SSIS (SQL Server Integration Services), qui permet de connecter différentes sources, de transformer la donnée “en chemin” (nettoyage, enrichissement, jointures…), et d’aller plus loin grâce à l’intégration possible de scripts C#.

Pour la partie Data Vision / reporting, j’utilise surtout Power BI (mise en forme des indicateurs, construction de tableaux de bord et partage avec les équipes métiers).

Autour de ça, je travaille aussi avec les “portes d’entrée” de la donnée : API et dépôts de fichiers. Ce ne sont pas des technos que je maîtrise côté infrastructure (elles sont fournies par les solutions en place), mais je sais m’y connecter et les exploiter.

Quelles sont les valeurs ajoutées d’un codeur au sein d’une équipe MarTech (comme CustUp) ?

Je vois plusieurs apports. D’abord, un profil développeur élargit le champ des possibles. Là où un consultant métier va maximiser l’usage des fonctionnalités standard, un développeur peut créer des briques sur mesure : automatisations, connecteurs, calculs spécifiques, reporting avancé.

Ensuite, je joue un rôle de facilitateur pour les autres consultants :

  • Je mets en place la base de données dont ils ont besoin ;
  • Je prépare les indicateurs pertinents ;
  • Et je construis ou j’adapte les flux pour que leurs recommandations puissent être réellement mises en œuvre.

Enfin, le fait d’être intégré à l’équipe MarTech change tout : on se parle directement, on partage la même vision des projets, et il y a moins de frictions entre la vision métier et la réalité technique.

Et puis, mes expériences m’ont beaucoup sensibilisé à la vision client et métier. Quand je code, je pense à la personne qui va utiliser l’outil derrière. Ça influence la façon dont je structure les bases, calcule les KPIs et prépare les données pour qu’elles soient compréhensibles par les métiers.

As-tu des “bonnes pratiques tech” à partager avec ceux qui interviennent sur des projets MarTech (CRM, CDP, marketing automation, etc.) ?

Oui, j’en vois trois, très concrètes.

Bonne pratique n°1 : Faire les choses dans le bon ordre

J’ai déjà vécu des situations où on définissait des KPIs avec le client… avant d’avoir vérifié que les données nécessaires existaient vraiment ou étaient exploitables. Depuis, j’essaie de faire avancer en parallèle la définition des besoins métiers et la vérification de ce qui est disponible dans la donnée (profondeur historique, qualité, fréquence de mise à jour…).

Ça évite de promettre des indicateurs impossibles à calculer. Et ça fait gagner du temps à tout le monde.

Bonne pratique n°2 : Être très rigoureux sur l’organisation

Concrètement, je recommande de nommer très clairement les tables, colonnes, fonctions, ainsi que de bien structurer les dossiers (tout doit être rangé au bon endroit).

C’est tout bête, mais ça évite de perdre des heures à chercher un script qu’on sait avoir écrit… sans se rappeler où on l’a rangé.

Bonne pratique n°3 : Savoir lire une documentation technique

Pour moi, savoir lire une doc technique, ce n’est pas un bonus, c’est la base. Sur des projets MarTech, on interagit avec plusieurs solutions. Il faut être capable de :

  • Trouver l’info utile ;
  • Comprendre ce que fait réellement une fonction ;
  • Voir ce qu’elle attend comme paramètres et ce qu’elle renvoie.

Sinon, on peut chercher très longtemps des réponses qui sont déjà écrites, noir sur blanc, dans la documentation.

L’IA et le vibe-coding jouent de plus en plus un rôle important dans ton métier. Que peux-tu nous dire là-dessus ? Qu’est-ce qui change pour toi ?

Je vois l’IA comme un outil très utile, mais qui ne remplace pas le développeur. Car, pour que l’IA soit vraiment un plus, il faut déjà :

  • Avoir les compétences techniques : si on ne connaît pas le langage ou le framework, on ne peut pas juger si le code généré par l’IA est cohérent, propre ou performant.
  • Et rester (très) critique : ce que propose l’IA, ce sont des suggestions, pas des vérités. Il faut tester, relire, adapter.

Dans mon quotidien, j’utilise l’IA de différentes façons :

  • Automatiser les tâches répétitives : par exemple, générer des getters/setters en C# pour un grand nombre de variables. C’est chronophage, peu intéressant intellectuellement, et l’IA le fait très bien.
  • M’aider à réfléchir sur des indicateurs : quand je veux calculer un KPI un peu complexe, je peux expliquer le besoin à l’IA, voir comment elle propose de le calculer, puis réutiliser ou adapter la logique.
  • Décoder des erreurs compliquées : quand un log d’erreur fait 50 lignes, je peux le donner à l’IA pour qu’elle m’aide à identifier les points à vérifier en priorité.

Donc oui, l’IA change mon quotidien : elle me fait gagner du temps sur certaines tâches et m’aide parfois à débloquer des situations. Mais la responsabilité finale reste chez moi.

Qu’est-ce qui te plait le plus dans ton quotidien ?

La liberté d’organisation, déjà. En tant qu’indépendant, j’apprécie beaucoup de pouvoir organiser mes journées. Cette autonomie est importante pour moi.

Le lien entre le code et l’usage concret est également un point qui me plait. J’aime continuer à faire du développement et de l’informatique, tout en voyant concrètement :

  • Comment mes développements sont utilisés ;
  • Comment ils aident les consultants et les métiers ;
  • Comment ils permettent de mieux piloter l’activité.

Ce lien entre la technique et le métier, c’est clairement ce qui me donne envie de continuer dans cette voie.

Ce qui t’énerve le plus dans ton métier ?

Ce qui m’énerve le plus, ce sont les erreurs dans le code. Les messages d’erreur vagues, mal documentés, ou qui n’indiquent pas du tout où chercher… Ça oblige à passer du temps à tester des hypothèses une par une, parfois sans avoir d’indication claire sur la cause réelle du problème.

L’IA m’aide un peu sur ce point, parce qu’elle peut lire un log d’erreur très long, en faire une synthèse et suggérer des pistes à vérifier. Mais même avec ça, c’est aussi le rôle d’un consultant IT de savoir résoudre ce type de problèmes.

Propos recueillis et retranscrits par Thibaut Huertas.