Changement d’adresse(s) – mise a jour des emails corporate chez Orange France Telecom

Comme l’a récemment souligné Sébastien Crozier dans un post « à charge », le plan d’adressage email corporate de Orange (France Telécom) change une deuxième fois en 5 ans:

@francetelecom.com / @orange-ftgroup.com / @orange.com

Indépendamment du débat sur le coût et les conséquences de ce changement pour l’opérateur, cette affaire va conduire de nombreux interlocuteurs d’Orange à (re)mettre à jour leurs carnets d’adresse.

Plusieurs centaines pour être précis dans mon cas, d’où le recours à AppleScript pour automatiser la mise à jour du domaine dans les adresses email. L’opération s’est effectuée sans encombre et je vais à nouveau pouvoir voir les photos de ceux qui m’écrivent dans mail.app !

Ci-joint le script permettant de faire la manipulation, n’hésitez pas à l’éditer si vous voulez conserver les « anciennes adresses », ni à vous en servir pour d’autres manipulations sur les emails de vos contacts. Inutile de rappeler qu’un backup de son Carnet d’Adresses est recommandé avant de lancer le script.

Il suffit de copier / coller le texte ci-dessous dans l’éditeur AppleScript et de le compiler :

<– couper ci-dessous –>

— Core program written in 2006-2007
— Updated Sept 2011 for @orange-ftgroup.com > @orange.com migration
— Works on a contact selection : test with one or two before running over all your address book database
— Thanks to Ben Waldie for helping me debug this — http://www.automatedworkflows.com/
— © Philippe Dewost 2011 // http://blog.dewost.com

set changeCount to 0
set errorCount to 0

display dialog « Warning: This script is designed to modify data! Be sure to back up your Address Book database first! » & return & return & « Do you still want to continue? »

try
doReplace(changeCount, errorCount)
on error theError
set archivedChangeCount to changeCount
display dialog « Main Dialog :  » & errorCount &  » error(s) happened. Had updated  » & archivedChangeCount &  » contacts so far. Error was  » & theError &  » … »
doReplace(archivedChangeCount, errorCount)
end try

on doReplace(changeCount, errorCount)
try
tell application « Address Book »
activate
repeat with aPerson in (get selection)
repeat with anEmail in (emails of aPerson)
set textOfEmail to (value of anEmail)
set email_id to id of anEmail
set email_label to label of anEmail
if textOfEmail contains « @orange-ftgroup.com » then

— update email
set newTextOfEmail to my searchReplace(textOfEmail, « @orange-ftgroup.com », « @orange.com »)
set value of anEmail to newTextOfEmail
set label of anEmail to « Work »

— keep soon deprecated address with « other » label
— Uncomment following lines to keep the « old » email with an « other » label
— try
— Corrected by Ben Waldie / AppleScript Guru
— set old_email to make new email at end of emails of aPerson with properties {label: »Other », value:textOfEmail}
— on error theError
— display dialog « Error adding email:  » & theError
— exit repeat
— end try

— Uncomment following line if instead you want to delete the email
— delete (emails of aPerson whose id is email_id)

set changeCount to (changeCount + 1)
end if
end repeat
end repeat
save — applies changes to the addressbook database once done
end tell
display dialog « Finished !  » & errorCount &  » error(s) happened. Have updated  » & changeCount &  » contacts. »
on error theError
set errorCount to (errorCount + 1)
set archivedChangeCount to changeCount
— display dialog « Loop Dialog : Error# » & errorCount &  » happened. Had updated  » & archivedChangeCount &  » contacts so far. Error was  » & theError &  » … »
doReplace(archivedChangeCount, errorCount)
end try
end doReplace

on searchReplace(origStr, searchStr, replaceStr)
set old_delim to AppleScript’s text item delimiters
set AppleScript’s text item delimiters to searchStr
set origStr to text items of origStr
set AppleScript’s text item delimiters to replaceStr
set origStr to origStr as string
set AppleScript’s text item delimiters to old_delim
return origStr

end searchReplace

<– couper ci-dessus –>

Ukibi aurait eu du bon

Le Carnet d’adresses, d’Ukibi à facebook

Ukibi-beta

En contrepoint du très bon « papier » (http://is.gd/78wInh) de mon « camarade » Henri Tcheng (qui ne semble pas être encore sur facebook), quelques remarques en désordre de la part d’un vétéran du domaine:

La notion de carnet d’adresses intelligent a véritablement émergé à la fin des années 1990, quand on s’est aperçu qu’Internet pouvait relier les hommes mais également leurs données, en vue par exemple de simplifier certains processus comme la gestion de leur carnet d’adresses et l’automatisation de sa mise à jour.

1999 est l’an 1 du carnet d’adresses intelligent, avec le projet Ukibi fondé par 3 français sortant du MIT (Huy Nguyen Trieu, Cyril Morcrette et Sébastien Luneau), qui met en place un système très astucieux de propagation de mises à jour de coordonnées baptisé StayInSync™. Ils s’appuient sur un protocole de description de contacts mis au point quelques années plus tôt (vCard, les fichiers .vcf) par le consortium Versit.

Amorcés par Mars Capital, ils lèvent 7 M€ auprès d’Europatweb et commencent à déployer Ukibi dans un contexte ou la connectivité n’est pas encore permanente (ce qui interdit par exemple la synchronisation en tâche de fond), contribuent au lancement du protocole SyncML pour étendre le carnet d’adresse unifié aux terminaux mobiles, mais sont entraînés par l’explosion de la bulle internet et du cash crunch de la téléphonie mobile provoqué par les folles enchères sur les licences 3G.

Une deuxième vague prend le relais, initiée par des acteurs américains beaucoup mieux financés, et qui se déplacent un peu plus vers le graphe social dont ils sont les « inventeurs » (même si la source est probablement dans le projet « 6 degrees » désormais oublié): ces acteurs ont pour nom Plaxo et LinkedIn, ce dernier s’acheminant progressivement vers une IPO planifiée pour 2011.

Puis arrive facebook, qui réussit le tour de force d’imposer en douceur une inscription / identification sous identité réelle, et réussit à conquérir 650 millions d’utilisateurs en quelques années. Le carnet d’adresses de facebook, qui semble un effet secondaire un temps occulté par la dimension « plateforme » (FBML, API, jeux sociaux, applis mobiles) est devenu en effet un actif soigneusement protégé ce que montre très bien l’article d’Henri Tcheng.

On est donc parti du carnet d’adresses, qui a souffert initialement d’un manque de connectivité (broadband fixe et mobile) et de standards (implémentations divergentes de SyncML) avant de « sortir » des réseaux télécom grâce à la (sur)puissance des terminaux et de devenir un des piliers des réseaux sociaux.

Cette évolution a d’ailleurs été largement facilitée par l’effondrement des coûts d’infrastructure matérielle (cloud) et logicielle (opensource) sous-tendu par la loi de Moore (entre 1999 et 2011 la puissance de calcul a été multipliée à cout constant par 250 à peu près)

Parallèlement, les utilisateurs sont devenus beaucoup plus confiants (ou naifs) et acceptent de télécharger leur carnet d’adresses ou de donner accès à celui-ci sur le web (via l’accès a leurs contacts Gmail ou Yahoo) ou directement sur leur smartphone.

Les opérateurs sont paradoxalement restés très en retrait : même si nombre d’entre eux ont des offres, celles-ci se sont fondues dans les interfaces utilisateurs lourdes de leurs portails surchargés, et sont pour la plupart difficiles à découvrir et complexes à utiliser.

Le graphe social, qui pendant longtemps dormait dans les systèmes de facturation, a donc lui aussi été aspiré à l’extérieur.

La suite dépendra de l’équilibre perçu par les clients entre la valeur du graphe (les liens) et la valeur des noeuds (les contacts), mais aussi de la faculté réelle de pouvoir reprendre simplement ce qu’on a confié. Sur ce dernier point, les enjeux ne sont pas tant techniques que stratégiques.

Ukibi, c’était donc en quelque sorte facebook, mais trop tôt, et pas assez financé. Je suis fier d’avoir participé à cette aventure.